Everything that comes before code, from requirements and processes to models, decisions and contracts, made query-able for humans and AI, and checked before it is handed to a developer or a dev-agent.
Code has had quality gates for twenty years: a linter runs on every change, a severity threshold fails the build, and a baseline lets an old codebase adopt the rule without a clean-up project. The information that code is built from has had none of that. Requirements sit in documents, processes in a modelling tool, architecture in slides, decisions in people's heads. Each is checked by whoever chooses to read it.
Two things changed. First, code is now generated from that information by AI agents at near-zero cost, so its defects reach production faster and in volume. Second, the quality of what the agent is given turns out to decide the quality of what it produces. On one controlled instrument, where the diagram was the only input the generator had, code generated from sequence diagrams degrades sharply below a measurable maturity level and improves with it above that level measured. Given contracts and examples beside the diagrams, the same diagrams fixed the layout and the interfaces of the code and changed none of its behaviour measured. On the industry's reference benchmark, a large share of real issue descriptions had to be hand-graded as under-specified because no machine check exists for them research. Repairing the input measurably raises the pass rate of the generated code research.
So the foundation of a semantic transformation, where an organisation's intent becomes something a person or an agent can query rather than re-read, is also a quality problem. Information that is not well-formed cannot be queried reliably, and information that has not been checked should not be handed on. This programme treats the two halves as one.
Query-able by humans and AI. Concretely: one identity per entity across every artefact that names it, stable identifiers that other artefacts can reference, machine-readable forms beside the human ones, and traceability that can be walked in both directions, from a requirement to the model that realises it and the test that proves it.
Gated before hand-off. A deterministic check runs on every change, at the author's desk first and in the pipeline second. Findings carry a severity, a threshold fails the build, a baseline lets a brownfield estate adopt the gate without a big-bang clean-up, and a graded score shows progress rather than a yes or no.
The map uses the four aspects and sixteen activities of the SAFe® Continuous Delivery Pipeline, as nomenclature only; no endorsement is implied. Each activity produces an artefact. The colour says whether that artefact is gated today, by a tool or by a practice, whether a project here is planned to gate it, or whether the gap is open. Most of Continuous Deployment carries no claim: this programme is about what happens before code, and a map coloured green all the way round would be marketing.
Where intent is formed. The programme's home.
Where the checks run.
Mostly no claim.
Governance and learning.
Every tool in this programme, and every third-party tool the map calls "covered", is measured against the same six properties. They are what separates a check that changes behaviour from a report that ages in a shared folder. Projects that lacked them are why the research tools of the last fifteen years are dormant: single author, grant lifetime, an IDE plug-in, no exit code.
One row per kind of upstream information. The state says how the artefact is gated today. "Threshold" and "baseline" are the contract's second and third properties; most tools outside API contracts lack them.
| Artefact | State | Tool or practice | Threshold | Baseline or score | What is missing |
|---|---|---|---|---|---|
| PlantUML models | covered | pumllint: rules, maturity score, ratchet, traceability, editor server, CI action | yes | score and ratchet | Diagram-versus-code drift (open). The best-evidenced gap in this table: one maintained model set scored 100/100 and carried 25 claims its code contradicts measured. |
| ARIS process models (EPC) | covered | aris2puml converts to PlantUML, defects preserved, then pumllint gates. The only CI gate found for EPC. | via pumllint | via pumllint | A gate inside ARIS itself needs its report script validated by an adopter. |
| Textual requirements | planned | StrictDoc, Doorstop, Sphinx-Needs, OpenFastTrace gate structure and links | no, pass/fail | none | Wording rules (INCOSE, EARS) exist only in commercial tools that cannot gate CI. A deterministic wording linter is planned; ambiguity detection stays advisory. |
| User stories | open | None maintained | No machine check for an under-specified story exists. | ||
| Specification prose | covered | Vale, markdownlint | yes | none | Vagueness in guards and conditions is not caught by prose linters. |
| Acceptance scenarios (Gherkin) | covered | gplint | partial | none | |
| BPMN process models | planned | bpmnlint and the Camunda plugins | errors vs warnings only | none | Single-model only. Cross-model checks, pragmatic guidelines and a score are planned as a plugin. |
| Decision tables (DMN) | covered | dmnlint, small rule set | no | none | |
| Cross-artefact consistency | planned | pumllint trace links requirements, decisions and diagrams and fails on unknown references | yes | none | Extending the identifier graph to tests and API operations is the first new project. |
| Architecture decisions (ADR) | open | adr-guard and adrpy-ai, both pre-1.0 | yes | none | The established ADR tools create files and validate nothing. |
| C4 architecture models | covered | Structurizr CLI validate and inspections | yes | none | |
| ArchiMate enterprise models | open | Archi's validator gives hints in the GUI; scripting can encode rules but has no CI path | no | none | No shared rule catalogue; a dozen small 2025 and 2026 attempts, none gate-capable. |
| SysML v2 and Capella | open | Pilot implementation and Capella validation rules | partial | commercial only | No standalone CLI gate; the only quality-gate product is commercial. |
| API contracts (OpenAPI, AsyncAPI) | covered | Spectral, vacuum, Redocly | yes | vacuum has a score and minimum | The reference pattern for a neighbouring artefact. |
| Schemas (Protobuf, GraphQL, JSON Schema) | covered | buf, graphql-eslint, sourcemeta jsonschema | yes | buf breaking gates change | |
| Data models | covered | SQLFluff, dbt-checkpoint, dbt_project_evaluator | yes | none | Conceptual and logical data models have nothing. |
| Threat models | open | pytm, Threagile | script your own | none | No risk-threshold exit flag anywhere. |
| Process design against reality | planned | Process-mining conformance checking, for example with PM4Py | script your own | none | The only method that compares a design with what actually happens. Needs an event log. |
| Vocabulary (glossary) | open | No gate. A check that lists terms used repeatedly and defined nowhere exists as an experiment script, not a tool | none | none | An undefined recurring term is a decision nobody wrote down. On one real program, 42 of 60 recurring terms had no definition measured. |
| Property-based invariants | covered | A practice, not a tool: property tests on the stated invariants, run against the original and against each rebuild | yes, by the test runner | none | Reaches behaviour no example scenario states. A property holds for the cases generated, not for all of them. |
Two exist. The others are planned, in the order their feasibility was assessed, and each stays "planned" until a repository exists. A planned project is a statement of intent, not a tool.
A linter and maturity scorer for PlantUML diagrams. The reference implementation of the gate contract, with the measured evidence behind the programme's central claim.
Converts ARIS process exports to PlantUML activity diagrams so pumllint can gate them. Makes a process checkable; never makes it pass.
One identifier graph across requirements, models, tests and API operations; fail on orphans and unknown references. Builds on pumllint's trace command.
Deterministic INCOSE and EARS rules with severities and a baseline. Ambiguity detection is reported, never gated, because its precision is too low to block a build.
An EPML reader and an EPC conventions ruleset, so process models from any tool that writes the interchange format can be gated.
Cross-model references, pragmatic modelling guidelines and a score, as a bpmnlint plugin.
A gate answers three questions with decreasing confidence. Is the artefact well-formed and precise? Fully mechanisable, and what the tools above do. Does the design satisfy a property someone stated, such as "every path reaches an end" or "payment never precedes approval"? Mechanisable for process and state models, with the property written by a person. Is the design the right one for the people it serves? Not mechanisable. Every automated check compares an artefact with another artefact; when both are wrong, agreement proves nothing. That question is answered by stakeholders in the room, by a walking skeleton, and by measuring the shipped product. AI reviewers can generate the questions for that room; the 2026 evidence on their agreement with human architects is too weak to let them close it.