DDC Framework: a metamodel for AI-assisted engineering

Context

Coding agents produce plausible output faster than a reviewer can check it. The failure mode is not bad syntax. It is a confidently invented file path, a library API from the wrong major version, a metric with no source. I was already running agent-assisted development across more than twenty repositories, so that failure mode compounded with every project instead of staying contained in one.

Problem

The quality of an agent's work was a property of the prompt, which made it a property of whoever happened to write that prompt on that day. There was no way to state a standard once and have every future session obey it, and no way to tell afterwards whether a session had obeyed it.

Approach

I separated the doctrine from the tooling. `.contexts/` holds the single source of truth as plain Markdown: 18 imperative rules, 9 modelling contracts, 25 stack manuals, 6 architecture models, 5 practices, 8 processes and the architecture decision records. `.claude/` is the compiled interface the agent actually loads: 55 skills discovered on demand, 21 specialised agents that each declare which contexts they must read, and 5 hook scripts wired into 6 lifecycle events (session start, pre-compaction, pre-tool, post-tool, prompt submit and stop). Nothing is written twice; the operational layer references the source of truth by path instead of restating it. The harness documentation itself spans eight domains: standards and architecture; frontend and design systems; BFF, APIs and backend; Firebase, Google Cloud and infrastructure; AI, agents and Vibe Coding; data and analytics; DevOps and automation; and product and agility.

Non-obvious decisions

• Doctrine lives in `.contexts/` and the agent-facing layer only references it. Duplicating a rule into a skill creates two versions of the standard, and the one that drifts is always the copy.
• Rules are split into always-active and path-scoped. An always-active rule costs tokens on every single turn, so the price of adding one is deliberately high; a rule that applies only to a glob loads when a file matches it.
• Anti-hallucination is a rule, not a review step. The grounding rule requires every file path, symbol, library version and environment variable to be confirmed on disk before it can be named. Verification precedes generation, which is the inverse of how a model wants to work.
• Enforcement is mechanical wherever it can be. A pre-tool hook rejects a commit that is not a Conventional Commit, a stop hook warns on ungrounded claims, and a session-start hook re-injects the bootstrap skill after every compaction, so losing context does not silently reset the standard.
• Every number published about the framework is counted from disk at the moment of writing, never remembered. The count of rules above is read from the directory, so the framework is held to its own grounding rule, and the framework's own test suite re-counts every published figure from disk on every run.

Outcome

The framework is the operating system for my agent-assisted work, and this platform is the evidence: specification, plan, per-task implementer and reviewer briefs, a progress ledger and a verification gate before any task may be called done. It is also the most direct answer I have to the question of how to run model-assisted delivery as a governed process rather than as a sequence of lucky prompts.