The reasoning contract and the platform built to run it.

What adoption inside a real codebase can and cannot prove.

LOGIC.md is a file format and TypeScript toolchain, 249 commits, three published npm packages, for declaring AI agent reasoning as YAML frontmatter: step DAGs, typed input/output contracts, and quality gates, compiled and validated against a canonical JSON Schema rather than left as prose. Modular9 is a 1,084-commit, solo-built Next.js application in which every specialist node can carry that exact contract, declared as an optional LogicSpec alongside a base system prompt and a stack of custom-skill modifiers. Modular9's own commit history tags nine milestones, M3 through M6, directly against the LOGIC.md integration, and two of LOGIC.md's own packages, its CLI and its MCP server, live inside Modular9's monorepo and run internally. This paper reads both dossiers together to separate what that adoption proves from what it does not: integration and survivability under production churn, not a measured quality lift, which LOGIC.md's own published benchmark explicitly failed to find.

A contract format needs a load-bearing deployment, not just a fixture.

LOGIC.md's own dossier is explicit about what its repository does and does not demonstrate on its own.

None of that answers whether the contract survives being wired into a real, evolving codebase under production pressure. Modular9 is the one place both dossiers describe the same integration from two separate vantage points: LOGIC.md's own repository, and the repository of the system that adopted it. A dry-run trace, a flat benchmark, and a schema-validation suite each tell you something about the format in isolation; none of them tell you whether a busy solo maintainer, shipping a separate 1,084-commit product on a separate deadline, kept the contract wired in once it stopped being new.

Vendored, not evaluated: the contract lives inside the system it is judged against.

Neither dossier describes LOGIC.md being pulled into Modular9 as an external dependency and evaluated at arm's length. Both describe a tighter arrangement: the tool's own packages sit inside the consuming monorepo, the consuming application's milestone tags are named after the tool's own integration phases, and the node primitive that carries the contract is the same primitive every specialist plugin uses. Five mechanisms, drawn from the two dossiers, describe how that arrangement actually works.

What the two dossiers actually measure, read without cherry-picking.

Scale, first: the two codebases are comparable in shape, not size. LOGIC.md is a small, focused toolchain; Modular9 is roughly four times the commit volume and carries a full deployment surface LOGIC.md does not need. That asymmetry matters for what follows: a small tool being vendored whole into a much larger, actively shipping application is a stronger integration signal than two similarly-scoped projects cross-referencing each other.

On output quality, the two available results do not agree with each other, and neither is a clean win for the contract format. LOGIC.md's self-published benchmark (2026-05-07) tested two models at n=10 per condition: Claude Sonnet 4.6 on a code-review task was already ceiling-bound (control 99, treatment 100); Llama 3.1 70B was flat to slightly negative across code-review, research-synthesis, and security-audit once seven NVIDIA NIM connection drops were excluded (logic-md, hard metrics). A separate 60-trial test against the third-party tool Archon (2026-05-06) is the only third-party comparison either dossier reports:

60-trial test (3 fixtures × 2 cases × 10 runs) against Archon, 2026-05-06 (logic-md, hard metrics).

Read plainly: LOGIC.md-via-MCP raised agreement on the full structured-output tuple, but lowered agreement on the verdict label alone, and cost 164% more runtime. Two of the three rows favor the stock prompt. Neither dossier reports a Modular9-specific experiment isolating the effect of enabling or disabling a LogicSpec on a live specialist node's output. What both dossiers do support is that the contract is present, wired into node composition across the plugin catalogue, and has survived eight months of continuous refactoring without being pulled back out. That survival is itself evidence, of a different kind than a benchmark score.

What neither dossier closes.

What survives production churn is evidence of a different kind than a benchmark score.

LOGIC.md's maintainer already repositioned the project's public claim after its own benchmark came back negative: from a quality-lift pitch to an auditability and governance pitch (logic-md, decisions). Modular9's adoption is consistent with that repositioning, not a rebuttal of it. Nothing in either dossier claims Modular9 is faster or more accurate because a specialist node carries a LogicSpec. What both dossiers support is narrower and more concrete: the contract format was cheap enough to vendor, version alongside nine of Modular9's own milestone tags, and carry through eight months of continuous refactoring, a 5,038-line switch collapsed to a 56-line registry, a major TypeScript upgrade attempted and reverted, a full security remediation cycle, three separate deploy targets, without being abandoned or quietly stripped out.

For a prospective adopter, the implication of reading these two dossiers together is narrower than either project's own marketing suggests. LOGIC.md is evidenced as an integratable, versionable file format that a solo-maintained, production application chose to vendor and keep. It is not evidenced, by either dossier, as a technique that measurably improves what a specialist node produces. Anyone adopting it on the strength of Modular9's example should adopt it for the same reason Modular9 apparently did: structure, contracts, and an audit trail, not a quality lift that neither project's own numbers support.

For LOGIC.md's own roadmap, the live schema-drift bug and the coverage gap around compiler.ts and executor.ts are the kind of defect that a second, independent, larger consuming codebase tends to surface over time; whether a future Modular9 dossier reports a bug traced back to that exposure is an open question the next compile should check. For Modular9's own security roadmap, the same production pressure that already forced two real fixes this cycle, the HTTP-status error-classification bug and the path-traversal vulnerability in getDocBySlug, is the same pressure the disclosed Row-Level Security and rate-limiting gaps sit under today. The dossier records intent to close them. It does not record a timeline.

The narrower reading holds up either way: a reasoning-contract format proved something by surviving inside Modular9, but what it proved is that a solo maintainer kept using their own tool once the pressure was real, not that the tool changed what any agent produced. Those are different claims, and only the first one has evidence behind it in these two dossiers.

Evidence: compiled from the logic-md and modular9 repositories on 2026-08-03, via their evidence dossiers at docs/dossiers/logic-md.md and docs/dossiers/modular9.md. Every number on this page traces to a file path, command output, or recorded test run cited in those two dossiers. Last updated: 2026-08-03.