Documentation

The Blueprint

The versioned description of what a product is, independent of how it is currently implemented. It carries the product's capabilities, its contracts, its data model, its rules and its constraints. A Blueprint survives a framework migration unchanged, because none of what it describes is a framework decision.

Blueprint versus technology

The split is the single most important idea here. What the product does, what it stores, what it promises and what it forbids belongs to the Blueprint. Which language, framework, database or deployment target expresses it belongs to technology. Confusing the two is what makes a rewrite a rewrite.

• Blueprint: capabilities, contracts, entities, rules, constraints
• Technology: language, framework, storage engine, runtime, host
• One Blueprint can be generated into more than one technology target

Capabilities

A capability is a reusable unit of product behaviour with a key, a version, an owner, a status and a set of products depending on it. Capabilities are discovered from your existing portfolio during the scan and created only when nothing in the graph fits. Every new capability joins the graph for every future product.

The capability graph

The portfolio as a library rather than a pile. The graph is what makes the reuse ratio a number you can see, and what lets composition prefer what you already own. A portfolio that cannot see itself rebuilds itself.

Composition

Turning a strategy into a Blueprint by selecting existing capabilities first, extending where an existing one nearly fits, and creating new ones only where nothing does. The composition result states which requirements each choice covers, so a reviewer can disagree before anything is planned.

Change sets

Work is expressed as typed operations — add a capability, change a contract, migrate a field — rather than as free-form edits. A typed operation can be validated, authorised, reversed and audited. A shell command cannot be any of those things.

Deterministic validation

Type checks, tests, contract checks and schema checks run before anything is put to policy, and none of them is a model assessing its own output. A change that fails validation never reaches a person's queue.

• Type and compile checks against the whole affected surface
• Tests, including the ones generated alongside the change
• Contract checks against every dependent capability
• Schema and migration safety checks

Policy

Validation answers whether the change is correct. Policy answers whether it is allowed. Rules are written one line at a time — the action, the outcome and the reason — so a non-engineer can review them. Some outcomes are configurable; a few are refused at every setting.

Builds and releases

Autonomous builds run in your repositories, land on branches and arrive as pull requests. A release is certified when all eight gates pass — Blueprint, build, policy, code review, security, QA, artifact provenance and rollback — and never because a build finished.

Provenance

Every shipped change carries the Blueprint version, the requirement it satisfies, the capability it belongs to, the agent that wrote it, the model that was routed to and the person who approved it. Captured as the change moves, so the answer is a lookup rather than an investigation.