MDCP synthesis
Type: agentic-system-analyses/types/agentic-system-synthesis.md
Bounded synthesis
From request to a documentation contract
MDCP is a repository-based documentation and context system, delivered as an agent skill plus a deterministic compile/check toolchain. This account covers its shipped documentation loop at commit 1a198715a4da72dd89bad93f84cf5d4b3ab56b01, with analysis cutoff 2026-11-08. SRC-1 supplies inspected implementation and declared workflows, not an observed agent run or causal experiment. The whole-system functional boundary includes authoring, maintenance, downstream publication and optional maintainer evaluation; it does not imply exhaustive inspection. The external agent host supplies inference, tools, conversational state and scheduling. MDCP's archive/rename notice is in scope, but the successor Merlon Docs is not. See the boundary and source register.
The operational starting point is a task interpreted by a host agent, not an MDCP scheduler. The installed skill directs the agent to choose one workflow, discover relevant project documentation through host search or guide indexes, and open one source shard at a time. Vendor skill policy and mutable project shards are separate objects: the former governs the work; the latter retain project intent, contracts and explanations for later work. Their force is interpreted guidance, not filesystem interception or guaranteed compliance. See RT-OBJ-mdcp, MEM-OBJ-shards and RT-BAP-skill-host.
The representative feature workflow connects intake to delivery in one shipped procedure. The agent scopes a work item, plans commit groups, creates a branch, edits audience-appropriate shards and indexes before product code, implements/tests against that contract, reconciles documentation with as-built behavior, validates and submits for review. Human review is conditional: headless defaults permit reversible work to continue, while destructive work, real scope changes and exclusively human input require stopping. Delivery means review submission, not acceptance, merge, release or deployment. Handoffs are chiefly between phases owned by one agent; optional host isolation does not establish an MDCP-managed worker protocol. See RT-RTE-feature-work and the workflow account.
Selective context, durable content and derived publication
MDCP's context mechanism is selective source reading. One-shard/one-workflow guidance limits requested loading qualitatively; it does not implement cumulative token accounting, eviction, conversational compaction or a child-return schema. An optional host fork can keep work in a separate context, but MDCP does not specify what crosses back. Documents remain available for another explicit search/read; an index link does not itself keep linked content in the model window. See RT-CLM-context-discipline and the memory annotation on RT-RTE-feature-work.
There is positive, bounded evidence for the size rationale. The repository's reported static dataset gives a median feature shard of 864 estimated tokens against a 61,941-token monolith: about 1.4% by estimated tokens and 1.5% by characters. This compares one feature shard with that repository's whole monolith, not task-matched alternatives. It supports the conditional claim that reading one shard instead of that monolith can reduce supplied text. It does not measure actual agent selection, total prompt overhead, search cost, recall, task quality or exercised savings. The dataset's date does not establish a measurement run on the frozen commit. See EPI-OBJ-context-size, EPI-RTE-context-size and EPI-CLM-context-size.
Persistence is primarily Markdown files, normally versioned in Git. Current shards can be replaced or deleted; ADRs preserve superseded decisions, and the research overlay explicitly preserves dated observations while linking evidence to durable positions and then normative clauses. An observation is not itself a rule. These links afford rationale inspection without guaranteeing that a later agent reads the reasons before following a clause. See MEM-RTE-shard-authoring and MEM-OBJ-research.
Compilation follows a different selector from task relevance: config, manifest links, in-scope transitive Markdown links and directory fallback determine its inputs. It reshapes selected content, rewrites location-dependent links and persists guides/monoliths and a heading registry. The registry has concrete later CLI and site consumers; it is access metadata, not a store of supporting arguments. The compilation-only shard cache is process-local working state, unlike persisted documents or optimizer state crossing later inference invocations. Derived pages and guides are not independent corroboration of their sources. See RT-RTE-compile-check, MEM-OBJ-compiled, MEM-OBJ-refs and MEM-OBJ-shard-cache.
Checking and repair have local authority
The toolchain supplies real mechanical rejection, not general prose-truth acceptance. In check, orphan findings reject before compilation. Otherwise outputs and refs can be written before later failures. Repair belongs to the caller; backups and Git are recovery options, not an all-output transaction. A pass covers selected enabled checks: links can be disabled or downgraded to warnings, Vale skipped, optional missing peers tolerated and coverage left non-strict. Direct core calls, mechanical shard import, peer fixes and registered callbacks do not share one universal approval gate. See RT-RTE-compile-check, RT-RTE-shard-import, MEM-RTE-peer-fix and RT-RTE-hook-extension.
Some checks do evaluate narrow truth-apt propositions. The optional path probe tests recognized path existence under specified roots and exemptions; it does not assess file behavior. The code-evidence hook derives a first lexical occurrence location, which can point to a comment before a declaration; existing line fragments are preserved rather than verified. Insert expansion imports text without accepting its truth. Arbitrary callbacks and external peer mutations prevent generalizing default assembly's reshaping behavior to every transformation. See EPI-RTE-path-probe, EPI-RTE-code-evidence and EPI-RTE-inline-inserts.
Semantic checking is prescribed separately. Review signals direct attention to sprawl; the host workflow chooses merge, split, move, reword, link, delete or leave, with a reason. Research guidance requires method, scope and caveats, and disclosure when a clause lacks evidence. These are evidence-sensitive prescriptions, not inspected instances of accepting a particular novel claim or integrating it after acceptance. CI can reject selected failures and generated-output diffs, but deployed mandatory merge protection and successful release remain unverified. See RT-RTE-doc-review, EPI-CLM-research-warrant and RT-RTE-release-admission.
Feedback changes candidates before it changes production
The strongest supported learning-related contribution is a wired, bounded maintainer feedback loop. The vendored trigger optimizer compares Claude-subprocess skill invocation against expected labels, retains failures/scores/history, requests revised descriptions and uses candidates in later evaluations. This is automatic trace-fed revision of retained behavior-shaping text, not merely log archival. The next inference inputs receive candidate and feedback state automatically; ordinary project-shard reads remain requested pulls. Trigger agreement is the evaluated objective, not successful task execution or prose truth. Test fields are hidden from proposal history, but selecting the best candidate using test scores means that set is not an untouched final evaluation. The returned description still requires a separate author action to update production frontmatter. See RT-RTE-skill-evaluation and EPI-OBJ-skill-description.
The following properties therefore remain distinct:
- Theory-builder conditions 1–4: doc-review guidance supports claimed localized rules and requested content-dependent use (conditions 1 and 2), while completed content-directed criticism and retained criticism shaping another round (3 and 4) remain uninspected. The optimizer affords localized candidate policy, wires its delivery and candidate/result reuse, but scores and revision requests do not establish formulated criticism with blame or criticism-led iteration. It does not establish all four conditions.
- Improved future capacity through criticism: no comparison establishes that criticism of consumed guidance improved capacity. Wired feedback-driven revision is a supported partial contribution, not demonstrated learning benefit.
- Reflection: the optimizer wires a bounded feedback capacity representing trigger outcomes and affecting the next evaluated description. Exercised production reflection is not established. Recurrence-driven changes to review thresholds, glossary or Vale rules are prescribed, not observed.
- Autonomy: computation proposes and selects within the bounded optimizer, but autonomous theory building or autonomous end-to-end production revision is not established. The separate installation decision remains outside automatic selection.
- Self-improvement: candidate changes can reach later evaluation inputs, but no supplied execution establishes exercised evidence-responsive organizational change and subsequent behavior causally depending on it. Production installation and its downstream causal effect are additionally unobserved. No exercised production self-improvement or successful improvement is attributed.
These assessments follow the separate property findings in RT-RTE-doc-review and RT-RTE-skill-evaluation; missing outcome evidence does not erase their inspected capacities.
For a task requiring small, durable project contracts and reproducible publication, the supported design is selective host reads plus deterministic derivation and conditional checks. For a task requiring enforced context limits, reliable recall, accepted research conclusions or autonomous semantic repair, this evidence does not establish those guarantees. Recorded task traces linking shard selection, edits, checks and later consumption would change the exercised-workflow assessment. A task-matched context comparison would address savings and quality; a retained criticism/revision/next-round chain would address theory building; installation and subsequent causal-use evidence would address production self-improvement. Broader guarantees would also require controls covering the alternate write/read routes, rather than stronger wording about the ordinary protocol. The report verification and profile verification retain no blockers or additional declared limits; the scoped evidence gaps below remain.
Limitations
| limitation | affected SRC IDs and record citations | inspected boundary | conclusion prevented | evidence that would resolve it |
|---|---|---|---|---|
| Source structure is not exercised operation or benefit | SRC-1; RT-RTE-feature-work, RT-RTE-compile-check, RT-RTE-release-admission | Shipped workflow, CLI and CI/release text; no registered agent run or experiment | Successful adherence, delivery beyond submission, publication, deployed withdrawal and comparative effectiveness | Traces linking request, reads, edits, diagnostics, submission and downstream consumption; outcome comparisons for benefit |
| Host behavior and inference are external dependencies | SRC-1; RT-CMP-host-model, RT-CMP-claude, RT-BAP-skill-host | Skill interface and evaluator calls, not host/provider implementation | Enforced window limits, fork visibility, actual grants, stable model identity or provider parameter behavior | Pinned host/provider contracts and deployment evidence, including context and permission traces |
| Included alternatives remain incompletely characterized | SRC-1; RT-OBJ-mdcp, MEM-RTE-shard-authoring, RT-RTE-skill-evaluation, RT-RTE-compile-check | Selected workflows and consumers; detailed other archetype products, UX/tutorial phases, evaluator-helper artifacts and precise site/backup policy remain incomplete | Exhaustive memory/route inventories, identical workflow behavior, complete feedback uptake or publication-safety comparisons | Accepted records tracing those particular products, admissions, transformations and later consumers |
| Static size evidence is corpus- and method-relative | SRC-1; EPI-CLM-context-size, EPI-RTE-context-size | Reported dogfood CSV and counting implementation; external tokenizer not executed or independently verified | Measured total prompt savings, task-matched efficiency, recall or causal quality gain; measurement provenance on the frozen commit | Provenanced measurements and matched task runs recording all loaded material, overhead and outcomes |
| Semantic acceptance and rationale use are unobserved | SRC-1; MEM-OBJ-research, MEM-RTE-shard-authoring, EPI-CLM-research-warrant | Research/authoring prescriptions, not an inspected claim-level acceptance instance | Accepted novel knowledge, evidence-entailing clauses, universal human approval or later rationale consultation | Individual claim inputs, criteria, scoped evidence-consuming decisions, admission identity and later reliance traces |
| Transformations and gates do not supply universal preservation or rollback | SRC-1; RT-RTE-hook-extension, MEM-RTE-peer-fix, RT-RTE-shard-import, RT-RTE-compile-check | Callback/import/fix wrappers and enabled check branches; dependencies and particular callbacks not frozen | Semantic preservation across all supported paths, per-content veto, transactional rejection or automatic recovery | Particular callback/peer implementations and inputs; broader admission controls and verified transactional/recovery behavior |
| Feedback wiring does not demonstrate criticism-led improvement or production self-change | SRC-1; RT-RTE-doc-review, RT-RTE-skill-evaluation | Prescribed recurrence tuning and bounded optimizer implementation; no supplied execution | Completed theory-builder conditions 3–4, improved future capacity, autonomous theory building, exercised production reflection or self-improvement | Retained content-directed criticism and next-round use; installation/causal-use traces; independently evaluated outcomes for successful improvement |
| Successor and excluded historical/infrastructure surfaces are outside assessment | SRC-1; boundary | Frozen MDCP commit; successor, legacy equivalence and detailed formal/infrastructure behavior excluded | Current successor capability/support, migration equivalence, formal verification or deployed protection correctness | A separately authorized evidence boundary for the relevant system or excluded responsibility |