Capability Coverage and Maturity
On this page5 sections
This page prevents guide breadth, editorial maturity, and implementation proof from being mistaken for one another. A subject may be well explained and not implemented. A mechanism may exist in code and lack accepted operating evidence. Review every claim along all three axes.
Maturity vocabulary
| Status | Meaning |
|---|---|
| Missing | No accountable coverage exists yet. |
| Scoped | The responsibility and intended boundary are named, but the chapter is not drafted. |
| Draft for study | Useful working material that has not passed the editorial and technical review bar. |
| Review ready | Complete enough for external architecture, technical, editorial, and usability review. |
| Validated | Review feedback is resolved and the material has passed its defined checks or lab evidence. |
| Operationally proven | A current implementation has repeatable, versioned production or production-equivalent evidence. |
Review ready describes the document. It does not mean the implementation is
operationally proven. Operationally proven is scoped to an exact workflow,
repository class, risk level, environment, version, and observation window.
Current coverage map
| Capability area | Guide status | Implementation evidence boundary |
|---|---|---|
| Factory definition and operating model | Draft and canonical coverage | Partial case-study evidence |
| Detailed architecture ownership and four synchronized views | Review ready | Architecture trace is documented; complete implementation conformance is unproven |
| Factory system inventory and governance decision rights | Review ready | Organization-wide inventory completeness and operating effectiveness are unproven |
| Authority, domain records, and orchestration | Draft for study | Several mechanisms traced; complete live path not proven |
| Orchestration component and runtime contracts | Review ready | Twelve component families are specified; full contract conformance is unproven |
| Agent architecture, tools, context, and memory | Review ready core chapter | Versioned case evidence with bounded gaps |
| Agent Factory and capability supply chain | Review ready architecture | Unified registry and lifecycle not proven |
| Tool, skill, and integration contracts | Review ready | Existing callable capabilities are not asserted to meet every contract field |
| Knowledge, retrieval, ontology, poisoning, and revocation | Review ready, including a domain-scoped five-level ontology maturity model | Production semantic registry, ontology release workflow, benchmark, deletion, and poisoning controls are unproven |
| Multi-agent topologies and autonomy selection | Review ready | Each workflow must still prove benefit and verifier independence |
| Repository onboarding and intelligence | Review ready architecture | End-to-end onboarding path not proven |
| Autonomous workflow portfolio | Review ready architecture | First bounded workflow only; wider catalog unproven |
| Testing, CI/CD, artifacts, and delivery | Review ready architecture plus earlier drafts | Complete production path not proven |
| Platform, scheduling, cost, and resilience | Review ready architecture plus runtime drafts | Fleet-scale scheduling and disaster recovery unproven |
| Enterprise operations, control tower, drift, and incident response | Review ready | SLOs, detection quality, response time, and failover are unproven |
| Agentic security, identity, privacy, and compliance | Review ready additions plus earlier drafts | Full adversarial and compliance evidence unproven |
| Governance controls and emergency authority | Review ready | Control operating effectiveness and emergency timing are unproven |
| Evaluation science and controlled learning | Review ready additions plus earlier drafts | Production optimization lifecycle unproven |
| Hands-on mastery | Thirteen executable specifications available | Accepted runs remain limited; the original golden path is blocked |
| Public-source integration (loop, harness, and context engineering; factory economics; skills-to-loops-to-factory taxonomy) | Review ready; folded into existing chapters across passes 5–8 | Sourced from public talks, posts, and one livestream — see the research canon for provenance; a structural split of the longest resulting chapters is planned but not done |
Evidence required to advance a chapter
A full technical chapter is not validated until it has:
- stable definitions and responsibility boundaries;
- an architecture, state model, or implementation contract;
- failure modes, threats, tradeoffs, and recovery;
- measures, evidence, and explicit nonclaims;
- primary references and versioned implementation sources where applicable;
- an executable or clearly labeled design exercise;
- technical and editorial review; and
- resolved feedback recorded in the changelog.
Evidence required to advance a capability
Operational proof requires an exact version, qualified environment, identity, policy, representative workload, independent evidence, failure and recovery exercise, observation window, and accountable acceptance. A screenshot, demo, merged change, or passing agent report is insufficient on its own.
How to use this map
Use the public Coverage view to inspect guide emphasis, maturity, and implementation evidence boundaries. Use the Reviewer Guide when providing feedback and the Changelog to see which claims moved.