Morphism Deep Research Synthesis Backlog

assetactive

Morphism Deep Research Synthesis Backlog

Source: morphism-deep-research-synthesis-backlog.md (ingested 2026-03-28)

Deep research synthesis for Morpshim: backlog, ecosystem harvest, and a repo-audit superprompt

What this project is and what already exists

From the repo+workspace artifacts available, this is a governance framework aimed at making AI agent fleets more reliable by turning “drift, inconsistency, and compliance violations” into measurable, enforceable invariants—and then wiring those invariants into CI, tools, and runtime workflows. fileciteturn8file86L1-L1 fileciteturn10file17L1-L1

The architecture is explicitly a single monorepo with a product web app, multiple TypeScript packages, and a Python engine. The stack called out includes a Next.js 15 app under apps/morphism/, a Python category-theory core under src/morphism/, an MCP server and CLI, and published npm artifacts at version v0.1.0 (CLI, MCP server, plugin bundle, agentic-math). fileciteturn5file3L1-L1 fileciteturn8file18L1-L1

Two important “proof you’re dogfooding governance” signals already exist:

  1. A kernel-invariant framing: seven invariants are used as the governing backbone (the snippet shown lists them with names like “One Truth Per Domain,” “Drift Is Debt,” “Observability,” etc.). fileciteturn6file53L1-L1
  2. A maturity-score + test posture: the workspace indicates a maturity scoring framework (max 125/125) and a sizable cross-language test set (181 tests, split across Python and TypeScript). fileciteturn5file3L1-L1

On the anti-drift / anti-hallucination side, you already have substantial primitives that many teams never ship:

  • A repository-scale DriftScanner + healer loop (scan + heal commands, dry-run and apply modes; “5 drift types”; configurable confidence threshold; a live scan example; and tests). fileciteturn7file45L1-L1 fileciteturn7file49L1-L1 fileciteturn7file57L1-L1
  • A “learned rules” path: morphism learn stores rules with SHA-256 dedup and maps categories to enforcement (with graceful “unenforced rule” reporting for unmapped categories). fileciteturn7file56L1-L1
  • A category-theoretic enforcement bridge (TS↔Python interop) that explicitly references Čech-complex / H¹ drift detection and κ (kappa) computation. fileciteturn10file58L1-L1 fileciteturn6file49L1-L1 fileciteturn6file51L1-L1

On distribution and “make it easy to adopt,” you already have a one-command installer concept: the plugin bundle installs MCP servers, scaffolds .morphism/config.json, and configures git hooks. fileciteturn8file71L1-L1 fileciteturn8file73L1-L1

This matters because it’s how Morpshim becomes a layer versus a research artifact: the real adoption bottleneck is often packaging + wiring, not algorithms.

Finally, the “enterprise posture” is already indicated by (a) the homepage tightening to “enterprise-standard sections,” fileciteturn7file58L1-L1 and (b) security hygiene work like resolving dependency vulnerabilities and modernizing monitoring. fileciteturn4file22L1-L1

Strategic framing: enterprise + SMB without splitting the product

The pitch you showed (“We make AI agents that don't drift… type safety for AI behavior”) is directionally correct, but you’ll get more traction if you lead with operational outcomes and delay the math until after the buyer is hooked.

A useful structure (compatible with your current landing-page direction around drift and trust) is:

  • Outcome promise: “Agents drift silently → you discover violations in audits → manual review doesn’t scale.” fileciteturn7file58L1-L1
  • Product form: governance CLI + MCP servers + dashboard control plane, installed quickly (you already have the plugin-bundle install and MCP surfaces). fileciteturn8file71L1-L1
  • Differentiator: “mathematically structured governance” as an internal engineering advantage, not the headline (you already describe category theory primitives and provable compliance). fileciteturn10file17L1-L1

For enterprise + SMB alignment, the most robust pattern is one core runtime, two “switchboards”:

  • SMB gets: defaults, “one-click install,” opinionated presets, and an opinionated dashboard.
  • Enterprise gets: policy editing, audit export, identity/SSO later, and provable supply-chain/security posture.

This pairs naturally with your current licensing posture: you’ve moved to BUSL/BSL-style licensing and specify a change date and change license (your PR summary indicates BUSL 1.1 with a future change license). fileciteturn5file34L1-L1 The BSL family is explicitly designed to be source-available now with automatic conversion later, governed by a Change Date and Change License. citeturn14search7

If you keep “math-first marketing,” you’ll attract builders; if you keep “outcome-first marketing,” you’ll close budget. The best landing pages do both, but in sequence.

A prioritized backlog that extends what you already have

This backlog is written to (a) build directly on your existing primitives (drift scanner, learned rules, MCP tooling, monorepo installer) and (b) converge to a pre-release product that is credible to both early SMB users and enterprise evaluators.

| Priority | Item | What it enables | Anchors in current repo | Risk if skipped | |---|---|---|---|---| | P0 | Unification contract for “run → evidence → decision” | One internal schema for traces, tool calls, policies, and proof artifacts (less wiring drift; easier dashboard + plugins) | You already have multi-surface tooling (CLI/MCP/app) fileciteturn5file3L1-L1 and an existing “rule store” path fileciteturn7file56L1-L1 | The system becomes a set of loosely related tools instead of a platform | | P0 | Governance kernel as a runtime module (not just docs) | Hard/soft constraints, stop conditions, refusals, provenance hooks, policy snapshots | Kernel invariants exist and are referenced as enforceable rules fileciteturn6file53L1-L1 | “Governance” stays aspirational; enterprise won’t trust it | | P0 | Dashboard MVP as control plane | Run timelines, rule hits, drift incidents, κ trends; workspace/tenant boundary; export-ready audit logs | You already have a web app fileciteturn5file3L1-L1 and a prior “hub” concept for dashboard/project mgmt fileciteturn4file33L1-L1 | Users can’t see value; debugging costs kill retention | | P0 | Tool permissioning + sandbox boundaries | Prevent excessive agency and insecure plugin design; allow enterprise-safe tool execution | You already distribute MCP tooling and installer scaffolding fileciteturn8file71L1-L1 | Fails common LLM security expectations (see OWASP LLM risks) citeturn17search0 | | P0 | Evaluation harness + regression gates for drift | Detect behavior changes caused by prompt/policy/config changes; supports “anti-drift” claims | Existing maturity scoring and CI gates exist fileciteturn10file48L1-L1 | You will ship regressions and lose trust early | | P1 | “Rule packs” + marketplace-ready plugin manifests | Reusable governance modules: policy pack, RAG pack, SOC2-ish pack; later signed bundles | plugin-bundle already formalizes install surfaces fileciteturn8file71L1-L1 | Every customer becomes a bespoke consulting engagement | | P1 | OpenTelemetry/OpenInference instrumentation across all surfaces | Vendor-neutral tracing + interoperability with observability backends | You already depend on OTel-related libs in deps churn fileciteturn10file59L1-L1; OTel defines traces as graphs of spans citeturn17search3; OpenInference defines span kinds for LLM/tool/retriever flows citeturn18search4 | Your dashboard becomes “yet another telemetry format” and enterprises resist adoption | | P1 | Claim-level evidence gating (“no evidence → hedge/tool”) | Concrete anti-hallucination posture, not just “trust us” | Your existing drift + learned rules system can host additional rule categories fileciteturn7file56L1-L1 | Users interpret incorrect outputs as product failure | | P1 | Harden packaging and provenance | SBOMs, provenance attestation, secure publishing, enterprise procurement readiness | You already track dependency vuln posture strongly fileciteturn4file22L1-L1; npm trusted publishing uses OIDC to remove long-lived tokens citeturn12search2; SLSA provenance defines verifiable “where/when/how built” citeturn16search3; CycloneDX defines SBOM for dependency inventories citeturn15search0 | Procurement stalls; supply-chain reviews block enterprise pilots | | P2 | “Bring your own agent framework” adapters | Normalize LangChain/LlamaIndex/hand-rolled systems into Morpshim primitives | MCP protocol is increasingly the connective tissue for tool integrations citeturn0search0 | You’re limited to Morpshim-native users at first | | P2 | Red-team automation + security test suites | Continuous prompt-injection and tool-misuse testing | OWASP LLM Top 10 highlights prompt injection, insecure output handling, insecure plugin design, and excessive agency as key risks citeturn17search0 | Breaches or embarrassing exploits become early brand damage |

The key idea: P0 is “make the machine legible and safe” (unification, kernel, dashboard, permissions, eval gates). P1 is “make it interoperable and enterprise-buyable” (OTel/OpenInference standardization, evidence gating, supply-chain posture). P2 is expansion.

Harvesting top governance and anti-drift tools into Morpshim primitives

The ask “integrate the best features of the top 10 governance/anti-drift/anti-hallucination tools and transform them into Morpshim language” becomes tractable if you treat external tools as feature donors, not dependencies.

Below is a pragmatic “top tools → feature harvest → Morpshim translation” map. Each external tool is cited from its own docs, and each “translation” is expressed as a Morpshim primitive that can compile to your invariant + metrics core.

| External tool | Best feature to harvest | Why it matters | Morpshim translation target | |---|---|---|---| | entity["company","Anthropic","ai company"] MCP | Standard protocol for connecting models to tools/data; promotes interoperable tool surfaces citeturn0search0turn0search1 | Avoids bespoke integrations; supports “light tooling” with plug-in extensibility | Tool Surface Primitive: strict schemas + capability scopes; adapters become functors from “external tool schema” to “Morpshim tool schema” | | entity["company","OpenAI","ai company"] Agents.md (with AAIF context) | A shared convention for agent rules and boundaries; standards momentum via entity["organization","Linux Foundation","nonprofit consortium"]’s entity["organization","Agentic AI Foundation","open standards org"] citeturn19news46turn19news47 | Helps you sell “governance as a layer,” not “another agent framework” | Rule Canon Primitive: human-readable rules compile to enforceable constraints; integrate your existing SSOT/AGENTS governance posture | | entity["organization","Open Policy Agent","policy engine"] | Policy-as-code engine that decouples policy decisions from enforcement and supports many deployment modes citeturn11search2turn11search4 | Enterprise buyers already understand PDP/PEP patterns | Policy Decision Primitive: Morpshim exposes a PDP API; PEPs are MCP tools, CLI hooks, and web app middleware | | entity["company","Amazon Web Services","cloud provider"] Cedar / Verified Permissions | Fine-grained authorization policies decoupled from app logic; emphasizes correctness and formal methods in the ecosystem citeturn11search0turn19search1 | Gives you a credible story for tool permissioning, tenant policy, least privilege | Authorization Primitive: Morpshim policy grammar for tool permissions; compile to deterministic allow/deny + audit reasoning | | entity["organization","Guardrails AI","llm validation toolkit"] | Validator concept + explicit “on_fail” policies (re-ask, fix, raise) for output quality control citeturn8search0turn8search2 | Converts vague quality goals into programmable enforcement | Constraint Primitive: constraints + repair operators; treat “on_fail” as morphisms that map invalid outputs back into valid space | | entity["company","NVIDIA","semiconductor company"] NeMo Guardrails | Programmable guardrails with a dedicated flow language (Colang) and built-in rails (jailbreak, moderation, hallucination checks) citeturn8search3turn8search1 | Demonstrates how “guardrails” evolve into system behavior, not just post-checks | Workflow Primitive: typed dialogue/agent flows; compile to a run graph where each transition is checked against invariants | | entity["organization","Promptfoo","llm testing tool"] | Red teaming/testing aligned to OWASP LLM Top 10 and continuous regression testing citeturn17search1 | Converts new vulnerabilities into permanent test suites | Adversarial Eval Primitive: security test corpus + gates integrated into CI and dashboard incidents | | entity["organization","LangChain","llm framework"] LangSmith | Trace + monitor agent execution; supports monitoring dashboards, alerts, and OpenTelemetry integration citeturn9search11turn9search5turn9search6 | Shows “what a governance dashboard must feel like” in practice | Trace Primitive: standard span model + run IDs + tool-call timelines; compile Morpshim runs into OTel/semantic conventions | | entity["company","Arize AI","ai observability company"] Phoenix | Open-source tracing and evaluation, designed for experimentation and troubleshooting; uses OpenTelemetry/OpenInference citeturn9search1turn9search8turn9search0 | Gives you an open-source-friendly blueprint for dashboard UX | Observability Primitive: OTel-native spans + eval annotations; Morpshim can export/import traces with OpenInference keys | | entity["organization","Ragas","rag evaluation library"] | Component-wise RAG evaluation metrics (faithfulness, context precision/recall, etc.) citeturn10search1turn10search5 | Makes “anti-hallucination” measurable, especially for retrieval-driven stacks | Metric Primitive: define evaluation functors from runs to scalar/vector scores; integrate into your κ / governance vector calculus |

Two “meta-standards” are worth folding in because they make Morpshim interoperable by design:

  • entity["organization","OpenTelemetry","observability framework"] defines traces as graphs of spans with standard semantics. citeturn17search3
  • entity["organization","OpenInference","ai tracing conventions"] specifies semantic conventions for LLM/tool/retriever spans (e.g., span kinds). citeturn18search4turn18search5

That pair is the most direct path to “integrate the top tools” without re-implementing everyone’s telemetry and without locking into a single vendor.

image_group{"layout":"carousel","aspect_ratio":"16:9","query":["LangSmith trace timeline screenshot","Arize Phoenix tracing UI screenshot","OpenTelemetry trace spans diagram generative AI"],"num_per_query":1}

Dashboard control plane blueprint that matches your stated direction

Given your existing surfaces (web app + CLI + MCP server + healer), the dashboard should act as the control plane where three kinds of users get value:

  • Builders (SMB) want “why did it fail, and how do I fix it?”
  • AI/platform teams (mid-market) want “how safe is this agent fleet, and what changed?”
  • Governance/security (enterprise) want “prove enforcement, show audit trails, export evidence.”

A minimal dashboard that accomplishes this should expose:

Run timelines and traces: Each run becomes a traceable DAG of steps (plan/tool calls/validators/outcome). This maps naturally to OpenTelemetry’s trace model. citeturn17search3
Rule hits and invariant witnesses: For each run, list which rules fired, under which invariant, with what evidence. This aligns with your invariant table and “prove structural compliance” framing. fileciteturn6file53L1-L1 fileciteturn10file17L1-L1
Drift incidents and healing outcomes: Surface drift findings, whether fixable, and whether healed (dry-run vs applied). Your DriftScanner/healer already produces structured findings and supports confidence thresholds; the dashboard should simply visualize and persist them. fileciteturn7file45L1-L1
κ and maturity score trends: You already compute governance score via scripts and expose governance endpoints in the app (evidence exists of app routes invoking Python scripts). fileciteturn5file39L1-L1
Tool permission boundaries: This is where you directly answer OWASP risks like Excessive Agency and Insecure Plugin Design by making tool scopes explicit. citeturn17search0

Implementation-wise, you can keep “light MCP tooling” without sacrificing enterprise credibility by following a PDP/PEP split (policy decision in the kernel; enforcement at MCP/tool boundaries), which is exactly the philosophy behind general policy engines like entity["organization","Open Policy Agent","policy engine"]. citeturn11search2turn11search4

For pre-release readiness, the dashboard should also expose supply-chain and release evidence (SBOM generated, provenance present, trusted publishing status). npm’s trusted publishers model is explicitly about publishing from CI via OIDC rather than long-lived npm tokens. citeturn12search2 Supply-chain provenance in SLSA is about verifiable “where/when/how built.” citeturn16search3 SBOM formats like entity["organization","CycloneDX","sbom standard"] focus on dependency inventories and relationships. citeturn15search0

A comprehensive Trae + Claude Code prompt for repo-wide auditing and roadmap generation

You are a senior staff software architect + security-minded product engineer.
You are auditing the pre-release Morpshim monorepo.

GOAL
Produce a deeply specific, repo-grounded plan to ship a reliable, enterprise-credible governance layer for AI agent/tool systems in weeks. Your output MUST cite concrete files, directories, and call paths that you discover.

NON-NEGOTIABLES
- Read the entire repo (apps/, packages/, src/, scripts/, .morphism/ and docs/).
- Build an architecture and wiring model first; only then propose changes.
- Prefer simplification and unification over new abstractions.
- Be honest about unknowns; flag them as TODOs with “how to verify”.
- Assume pre-release: reliability, security, and debuggability > new features.

PHASE 1 — REPO MAP (OUTPUT FIRST)
1) Print a compact repo map:
   - Entry points (CLI main, MCP server entry, web app routes, Python engine entry)
   - Key packages and how they’re wired together (TS↔Python boundary especially)
2) List core “platform concepts” and where they live:
   - run / trace
   - rule / invariant / policy
   - tool / MCP server / plugin
   - evidence / provenance / citation
   - drift scan / healing loop
   - evaluation / test harness

PHASE 2 — WIRING TRACE
Trace a typical lifecycle end-to-end:
- user request (web or CLI) →
- governance evaluation & policy checks →
- tool calls (MCP tools, external tools) →
- validation + drift scan →
- storage/logging →
- response/outputs.
Output a step-by-step call graph with file references (functions/classes), including where errors propagate.

PHASE 3 — REDUNDANCY + UNIFICATION
Find duplicated logic across:
- rule evaluation
- schema/type definitions
- drift detection and “learned rules”
- trace/log structures
- tool wrappers/adapters
Propose a “single contract” (one schema family) for:
- Message/Run
- Tool invocation
- Policy decision results
- Evidence/provenance
- Trace spans (consider OpenTelemetry/OpenInference compatibility)
Include an incremental refactor plan: minimal PR-sized steps that keep tests green.

PHASE 4 — GOVERNANCE KERNEL / ANTI-DRIFT / ANTI-HALLUCINATION
Inventory current governance mechanisms and gaps.
Design a Governance Kernel module with:
- Hard constraints vs soft constraints (scoring)
- Provenance requirements (when evidence is mandatory)
- Uncertainty calibration outputs (confidence gating, “tool required” gates)
- Refusal and stop-condition policies
- Policy snapshot/version pinning (anti-drift)
- Regression suite for “behavior drift”
If the repo contains κ/kappa and drift-cohomology logic, explain:
- what is computed
- how it is used to decide pass/fail
- what could be standardized or simplified

PHASE 5 — MCP + PLUGINS + PACKAGING
Inventory all tool surfaces:
- MCP servers and tool schemas
- plugin-bundle installer behavior
- config file locations and formats (global vs per-project)
Propose:
- A “light runtime”: strict tool schemas, permissions per workspace/tenant, safe defaults
- A plugin manifest spec (capabilities, scopes, inputs/outputs, versioning)
- A packaging plan:
  - monorepo workspaces strategy
  - versioning and release automation
  - secure publishing and provenance evidence generation
  - prepublish checks (lint/typecheck/test/security scans)

PHASE 6 — DASHBOARD CONTROL PLANE MVP
Define the minimal dashboard that proves product value:
- Run traces (tool timelines, rule hits, errors)
- Drift incidents + healing outcomes
- κ/maturity score trends
- Policy/rule editor + simulator (“what if this rule existed?”)
- Workspace management + audit logs (exportable)
Specify what to log and what to redact (secrets/PII).

PHASE 7 — PRODUCT + TRACTION MODEL (NO INTERNET REQUIRED)
Propose:
- 2 early adopter personas (SMB builder and enterprise governance team)
- A single product that serves both via presets vs advanced controls
- A bootstrapping loop (open-core/hosted/paid packs), with pricing hypotheses
- 3–5 golden-path demos that never break and showcase unique value

PHASE 8 — ECOSYSTEM HARVEST INTO MORPSHIM LANGUAGE
Without browsing the internet, create a capability matrix of “best-in-class” features for:
- policy-as-code
- guardrails/validators
- tracing/observability
- evals/regression testing
- red teaming
- tool permissioning/sandboxing
Then propose how Morpshim should absorb these into Morpshim primitives:
- define the primitives (constraints, morphisms, functors, evidence, traces)
- define a “translation layer” from external tool styles to Morpshim style
- ensure user-facing rules remain simple; compile to formal core

DELIVERABLES (STRICT FORMAT)
A) Repo map + wiring diagram (text description)
B) Critical issues list (P0) with file pointers
C) Prioritized backlog (P0/P1/P2): title, rationale, impact, effort (S/M/L), dependencies, risks
D) Concrete refactor plan (PR-sized steps)
E) Pre-release checklist (tests, security, docs, release steps)
F) Product/traction plan + golden demos

START NOW: Print the repo map and entry points, then proceed phase-by-phase.

This prompt is intentionally “repo-first” and forces the tool to produce file-referenced recommendations instead of generic advice. It also explicitly connects (1) wiring and unification, (2) governance correctness, (3) MCP/plugin packaging, and (4) dashboard + traction, so you get one coherent roadmap rather than disconnected ideas.