AI Design Blueprint

Agent systems moved from demos to operations faster than teams learned to review, steer and govern them. AI Design Blueprint provides a public doctrine and validation layer for teams building software that performs consequential work on a person’s behalf.

The flagship doctrine contains ten principles for supervised delegation. A person sets intent, authority and constraints, then inspects, steers and approves the work an agent executes.

The ambition is legible autonomy, not invisible intelligence.

The standard is designed for developers and teams who need a shared definition of good agentic design. The principles are published for people and machines through:

• the public site

• a public MCP endpoint

• llms.txt

• installable agent packs

The validator makes alignment inspectable rather than merely asserted. The product’s position is simple: run by agents, governed by humans.

Join the closed beta

This doctrine isn’t theory. It’s what AI Design Blueprint runs on: a validator that checks each governance claim against the code meant to enforce it, so a control counts only when it’s real. The same instinct as the harness above, pointed at production.

It’s in closed beta now, a small cohort with real onboarding. If you want to hold your own agentic setup to these rules, you can request access here: https://aidesignblueprint.com/en/launch

Run by agents. Governed by humans.

The core problem was turning governance language into something a codebase could be checked against.

The main challenges

• Abstract principles: Prose can say that approvals, hand-offs and blockers should be explicit, but prose cannot fail a build.
• Severity and prioritisation: The validator had to distinguish a production-blocking trust failure from a hardening recommendation or polish issue.
• Model variance: Byte-identical input produced recorded score spreads of roughly 20 to 67 points.
• Self-reinforcing evaluation: Feeding a prior run back into evaluation created apparently stable scores for the wrong reason.
• Machine-first distribution: The doctrine had to be installable and queryable by coding agents, not only readable by humans.
• Avoiding perfection loops: A validator strict enough to matter still needed to let teams ship with clearly separated hardening work.

The doctrine is authored in canonical Markdown, parsed into structured JSON and published simultaneously for people and machines.

Distribution

The distribution surface includes:

• a streamable HTTP MCP server with 29 production tools
• six installable packs
• llms.txt
• a public integrations repository

Generated assets are deterministic, guarded against non-production URLs and synchronised by CI.

Validation

architect.validate makes the doctrine executable. A caller submits implementation context, and a pinned reasoning model evaluates it against the ten principles using a strict JSON schema and an explicit untrusted-input boundary.

Then deterministic server code, never the model:

1. coerces severities
2. calculates the score
3. enforces the grade caps

Every finding includes a verdict, severity class, evidence and a recommendation. Every run receives a recovery handle before the model call, remains private by default and can be retrieved through its persisted result.

Consensus and certification

Consensus runs unanchored evaluations in parallel and aggregates median scores, per-principle mode verdicts and stability. Certification adds an adversarial second pass bound to a code fingerprint and refuses the badge if the audit record cannot be written.

The validator is also run against its own product. Self-review results, including harsh runs, are preserved so score changes can be classified before they drive a product decision.

The project made several deliberate trade-offs.

1. Only production_blocker findings deduct from the headline grade. Hardening and polish findings remain visible without making production readiness mean perfection. The trade-off is a documented score ceiling until a principle genuinely becomes aligned.

2. Consensus defaults to three unanchored children. An experiment showed anchored consensus reaching a standard deviation of 0.00, while unanchored runs exposed 13.97 on identical code. The choice accepts extra evaluation cost to avoid false stability.

3. Submitted code is not persisted, except for an opt-in 24-hour certification hold. This privacy decision means the validator cannot fully distinguish a regression from a pre-existing miss.

4. A production-ready badge cannot exist without its audit row. Availability is traded for inspectability, so a failed audit write fails closed.

5. Partial evidence cannot mint production-ready. Focused reviews are capped at 74/C, closing what the repository calls a trust-forgery hole.

6. Doctrine, not runtime. The product validates doctrine alignment, not runtime correctness, security or compliance. That boundary is repeated in the tool description, report UI, FAQ and marketing material.

7. MCP is the primary distribution bet. Hosted streamable HTTP is the main path, with packs supporting agents that do not use MCP. The repository does not claim this was the only possible distribution choice.

What shipped

• Ten-principle public doctrine for supervised delegation
• Three companion lenses, seven runnable patterns and 103 curated examples
• Ten application guides and six installable agent packs
• Public MCP server with 29 production tools, including 12 public tools
• Validator, consensus and certification flows with replayable readiness reports
• Governed-session runtime with typed approval gates

Evidence of impact

• Bridge self-audit: improved from 35/F to 100/A over 14 iterations, with certification confirmation.
• Registry quality: Glama showed three A ratings for License, Quality and Maintenance.
• Closed-beta learning: three anonymised tester receipts each led to a shipped fix.

What the testing revealed

• Byte-identical input produced score variance of roughly 20 to 67 points.
• Anchored and unanchored consensus produced standard deviations of 0.00 and 13.97.
• A four-iteration certification stress test never crossed the stability threshold, so certification was correctly refused.
• A preserved consensus self-review reached a median 74/100, grade C, with six of ten principles aligned, one production blocker and three hardening findings.

Review-time savings, revenue, MCP consumer counts and adoption at scale are not measured.

The strongest part of the work is its honesty architecture. Severity classes allow a result to be shippable with notes, fixtures preserve unflattering runs, and score changes are treated as rubric questions until evidence shows a regression or improvement.

What failed and changed

• Anchored consensus produced perfectly stable scores for the wrong reason because the evaluator was reading its own prior verdict.
• A duplicated design rule drifted silently and allowed a large violation count to remain below the expected guard.
• Early CI gates reported failures without blocking them.

Each failure led to a structural correction: unanchored consensus, single-sourced executable rules and required enforcement lanes.

Known limitations

• The surface and spec lenses have uncalibrated v1 scoring.
• Regression-versus-miss classification is unsolved.
• Small artefacts can struggle to reach certification stability.
• The validator cannot assess runtime correctness, compliance or visual behaviour.
• Truncated input can produce misleading first-pass findings.

A second version would improve anchoring resistance, calibrate the younger lenses and address the regression-versus-miss gap.

Trust in agentic systems has to become an artifact.

The properties that mattered most ended up as typed records, fingerprints, caps or fail-closed checks because prose versions of the same promises drifted.

The public prototype surface includes:

• Public MCP server: https://aidesignblueprint.com/mcp
• Agent discovery document: https://aidesignblueprint.com/llms.txt
• Agent entry point: https://aidesignblueprint.com/en/for-agents
• Trust and data handling: https://aidesignblueprint.com/en/for-agents/trust-and-data-handling
• Published self-review: https://aidesignblueprint.com/en/readiness-review/36163b90-74f5-47d6-b735-bdfb25be596e
• Public case studies: https://aidesignblueprint.com/en/case-studies
• Agent packs and setup guides: https://aidesignblueprint.com/agent-assets/
• Public integrations repository: https://github.com/aidesignblueprint/integrations
• Authenticated AIDB Studio workspace: live but access-gated

Private run fixtures and private product-repository paths are intentionally not exposed as public links.

Experience

A developer can:

1. discover the standard through registries, llms.txt, the agent pages or a README badge
2. install it with one command
3. start validation through an MCP tool call
4. follow progress through recovery handles and heartbeats
5. inspect findings grouped by principle
6. act on the recommendation and next_step

Each finding includes a verdict, severity class, evidence from the submitted identifiers, a recommendation and a next step.

Severity is communicated in words such as production_blocker and hardening_recommended, not colour alone. Error and refusal states use typed enums.

The report pages were not explicitly audited for screen readers or keyboard navigation in the available evidence. The product’s surface lens does define accessibility requirements including target size, focus visibility and reachable destructive confirmations, and treats failures of those requirements as production blockers rather than polish.

Internal testing

Internal testing covers validator core behaviour, tool enumeration, generated-asset parity, disclosure copy and policy conformance. Self-review was preserved across multiple dates, including the 74/C consensus fixture and the AIDB Studio assessment with failures and later higher-scoring arcs.

Calibration

Anchoring and variance tests changed the product. They led to:

• unanchored consensus
• an N=3 default
• best-effort reproducibility disclosure

A four-iteration certification test kept stability below the required threshold and correctly refused every certification attempt.

External testing and rollout

External testing used a closed beta with invite and activation controls, a 14-day access window and three anonymised tester receipts that each led to a shipped fix. The actual cohort size is not published here.

Public rollout used registries, a CI-synced integrations repository, installable packs and a prelaunch site mode where the doctrine is public while commercial routes remain gated.

Still unvalidated or unmeasured: external adoption at scale, willingness to pay and time savings.

AI Design Blueprint is an evolving standard, not a guarantee of safe deployment.

Validation checks structural alignment with the ten principles. It cannot prove runtime safety, runtime correctness, security, regulatory compliance or visual quality, and it is intended to sit alongside a test suite rather than replace one.

LLM scoring has measured variance and every result carries best-effort reproducibility. Consensus can narrow variance, but a standard deviation of zero can itself be a cache or anchoring artifact.

A passing report is not a certification of an organisation’s deployment. Findings require human interpretation, and truncated or incomplete submitted context can degrade the meaning of a result.

Claims about adoption and external impact are limited to the evidence recorded here. Single-source reports are labelled as reported. Review-time savings, revenue and MCP consumer counts are not measured.