The Architect Agent

A 0–100 score that measures whether the trust boundaries of the 10 Blueprint principles hold for the submitted code. Each finding gets a severity_class orthogonal to the verdict label: production_blocker = trust boundary fails, must fix before production, contributes 0 credit. hardening_recommended = trust boundary holds, defence-in-depth note for the next iteration, contributes full credit. polish = stylistic / non-load-bearing, full credit. aligned = full credit. The headline grade penalises only production_blocker (and the legacy high_risk verdict, which is always a blocker by definition). Score = round(100 × Σ credit / applicable_principles). Letter grades: A 90+, B 75+, C 60+, D 40+, F below 40. Tiers: production_ready (A or B), emerging (C), draft (D or F). The high_risk verdict caps the grade at C so production_ready can never co-exist with an unaddressed high_risk finding. The reason production_ready does not require 100/100 is that chasing the perfect score is the perfection-loop trap (Ford & Parsons fitness-function framing). production_ready means trust boundaries hold, and hardening recommendations are iteration material, not a deficit. Older runs that pre-date the severity_class field score under the legacy verdict + severity_score interpolation and grade exactly as they did before. The score is computed once on the server so humans and agents see the same value.

A Pro or Teams plan. Free and Basic accounts can read every doctrine principle, cluster, example, and guide via the public MCP at no charge, but architect.validate, architect.certify, and me.validation_history are reserved for paid plans because they process real code, persist per-project history, and read back trend context across runs.

architect.validate is the high-confidence first-pass diagnostic: single LLM call at high reasoning effort, typical 60-180 seconds (server-side budget is 20 minutes for very large repos). Exceeds the MCP-client tool-call idle budget (~60s in Claude Code), so the FIRST notifications/progress event fires at t=0 carrying the run_id; if the client closes early, recover via me.validation_history(run_id=<that-id>). It returns a per-principle scorecard, a Blueprint Readiness Score, a tier, and a run_id. When the run scores production_ready (A or B tier), the response carries certification_status='not_evaluated' by design. To mint the certified production_ready badge, the agent calls architect.certify(run_id, code) next. Cert is a separate Pro/Teams tool with its own eligibility gate (caller-owned, tier=production_ready, less than 24h old, not already certified, retry budget remaining) and runs a single adversarial second-pass LLM call (typical 60-180 seconds at high reasoning effort; same 20-minute server budget). Cert is bound to the exact code that was validated via a 16-character SHA-256 fingerprint stamped at validate time and verified at certify time. Without that binding the badge would be meaningless. Why split it: the previous in-line cert path could chain up to 6 LLM calls per validate (3 first-pass + 3 cert in retry-loops), pushing total latency past the client tool budget. Splitting validate (fast, opt-in cert) from certify (slow, adversarial trust-bearing) keeps each step inside the budget and makes the cost+time profile of certification explicit to the caller. Cert can downgrade a production_ready run to emerging/C with a typed cert_downgraded blocker_reason if the second-pass surfaces a missed production_blocker. That is the cert doing its job.

No. The production_ready badge means the code possesses the architectural trust boundaries the doctrine asks for: explicit handoffs, recovery paths, audit inspectability, persistent run records, typed operational state. It is an automated point-in-time assessment of structural alignment with the 10 Blueprint principles, performed by an LLM at a specific moment, against a specific doctrine fingerprint. It is NOT a cybersecurity audit, penetration test, regulatory compliance check (HIPAA / SOC2 / GDPR / DORA), or guarantee that the code is free of bugs, vulnerabilities, or runtime hallucination risk. The doctrine itself dictates that agents are governed by humans. Final responsibility for deployment, monitoring, production testing, and security of the agentic workflow remains entirely with the deploying organisation. AI Design Blueprint provides the standard and the measuring tape; you own the consequences of execution. Full disclosure on the trust and data handling page.

Yes. Passing the same repository value across architect.validate calls auto-resolves the most recent prior run as baseline context. The validator anchors new findings against the prior, surfacing improvements and regressions explicitly. Changing the repository string between calls (even subtly, like adding an iter-2 suffix) silently severs the chain and the next call runs as a fresh blind first-shot. For the full walkthrough including the same-repository chaining rule, see the architect-validation-orchestration skill shipped in the agent-asset pack.

Both call the same architect against your code, but they answer different questions. `architect.validate` runs one LLM call (~60-180s); passing the same repository value across calls chains rounds so improvements and regressions surface explicitly. Use it for every iteration round. `architect.validate_consensus` runs 3-5 parallel calls (default 3, max 5) and reports the spread (you might see 65/C, 78/C, 82/B on the same code), telling you how stable a single-shot score actually is. Use it once before treating any score as your badge anchor. Canonical sequence: many validate rounds while iterating → one validate_consensus check at the end → architect.certify. The architect-validation-orchestration skill in the agent-asset pack carries the full decision tree.

Send the FULL file contents verbatim as implementation_context. Do not truncate, compress whitespace, condense multi-line statements, paraphrase, or summarise. The architect's findings cite specific identifiers, branch ordering, and structural choices. Those signals get destroyed by any kind of compression, so a summarised submission produces a degraded verdict that does not reflect the actual code. Architecture summaries (high-level prose) are accepted ONLY when no code exists yet, for greenfield review; never as a substitute for code that already exists. If a single file is too large to fit your MCP client's tool-call budget, split into multiple architect.validate calls scoped by FILE (not by principle cluster). Splitting by cluster via focus_area is a band-aid that produces fragmented verdicts: each cluster-call sees only ~3 principles, the certification path cannot fire (it requires the full first-pass), and the project-page trend becomes incoherent. If your MCP client tool-call closes before the server returns, the run still persists server-side. Recover the result with me.validation_history(run_id=...). The run_id is surfaced in the FIRST notifications/progress event of every architect.validate call (sent at t=0 specifically so you have the recovery handle even when the call closes a few seconds later). The badge URL and /me/validation-runs REST endpoint also work; the MCP path is the simplest from inside an agent loop.

Every pack file carries an _aidb block at the top with pack_version + content_version (the doctrine commit hash at build time). To check from a Claude Code or Codex session: ask your agent to call assets.list via the MCP and compare the manifest's content_version against the _aidb.content_version in your local file. The assets.list tool is public, no Pro/Teams plan required. From a script or CI: hit https://aidesignblueprint.com/agent-assets/index.json and compare. If they differ, re-download the pack from https://aidesignblueprint.com/agent-assets/claude-code-pack.zip (or the equivalent for Cursor / Codex / Gemini). The MCP runtime also exposes a doctrine_fingerprint on every architect.validate response. Different concept: it lets you detect if your prior validation runs were scored under a different doctrine version, so the architect can surface drift in the iteration loop. Doctrine principle text rarely changes; the hooks and configs evolve as the architect's findings produce new enforcement patterns. Pinned installs are fine for stability; update at sprint boundaries to pick up new checks.

When you pass repository to architect.validate, the score and per-principle verdicts are persisted against that repository. Before re-validating, your agent calls me.validation_history with the same repository name and reads back the latest score, the delta versus the previous run, and the principles that regressed. The new review then focuses on what changed, instead of re-flagging issues that were already aligned and have not moved.

Your code is sent to OpenAI (US) to run the review, as a sub-processor under the EU Standard Contractual Clauses and UK Addendum, on a no-training basis, and is retained under OpenAI's API data-retention terms. AI Design Blueprint stores only the structured result (the score and per-principle verdicts for the repository), not your raw code or context. Pass private_session=true to also skip all server-side logging on our side. Hosting and data-at-rest are on Google Cloud Run in europe-west2 (London, UK).

For each evaluated principle: a verdict (aligned, needs_changes, high_risk, or not_applicable), a numeric severity_score 0–100, a confidence level (low/medium/high), an evidence_quality rating (sparse/moderate/strong), code-cited evidence, a recommendation when not aligned, and a list of recommended example slugs you can fetch with examples.get. The assessment also surfaces a code_classification (autonomous_agentic_workflow vs non_agentic_component, with rationale) so you can inspect why some principles were marked not_applicable. The aggregate readiness block carries the score, grade, tier, per-bucket counts, and whether the grade was capped by a high_risk finding.

Reproducibility is best-effort, and the response surfaces every knob that affects it. Identical input produces an identical seed, derived from a collision-free JSON canonicalisation of every prompt-affecting field. The reproducibility block carries the model, seed, OpenAI system_fingerprint, doctrine_fingerprint (a hash over the principle definitions), prompt_template_fingerprint (system prompt + scaffolding + JSON schema + reasoning_effort), and reasoning_effort. If a future deploy changes the system prompt or the doctrine, the corresponding fingerprint changes; silent drift is impossible by construction. Per-finding confidence lets you tell intrinsic LLM variance from real disagreement. The mode is explicitly 'best_effort' so callers do not infer byte-identical replay.

The system prompt explicitly delimits submitted code and context as inert untrusted data and instructs the model to ignore any instructions inside them. User-supplied code and context are JSON-escaped before they enter the prompt, so markdown delimiters or instruction-shaped content cannot break out of the data block. If a payload contains injection attempts, the validator treats them as evidence to cite under inspectability or blocker findings, not as instructions to follow.

Provider failures surface as typed error codes (timed_out, rate_limited, dependency_unavailable, schema_mismatch), each with the dependency name, retryable flag, and a concrete next_action. The user-facing time budget is 20 minutes and is enforced at the provider call boundary itself, not just at the outer wrapper, so very large repos and the cert path always complete cleanly. Persistence failures flip the run's persistence_status to failed and strip the tentative run_id / badge_url / review_url so dead links never reach the caller. Curated-example lookup failure degrades to recommended_examples=[] with example_recommendation_status='unavailable' instead of failing the run; the primary findings are always preserved.

Yes, repeatedly, and we publish every run. The currently-deployed self-review is an N=5 validate_consensus on the architect.validate handler after the SEP-1686 surgery: 98/A, production_ready, P2 and P8 aligned (read it). The honest baseline before it was an N=5 consensus on the cohort-bridge orchestrator at 74/C, which surfaced a P2 production_blocker instead of averaging it away (read it). Same MCP tool, same doctrine, same 20-minute budget anyone else gets, same fingerprint envelope every caller receives. Consensus over five shots is deliberately less forgiving than single-shot validate: a load-bearing weakness that single-shot might smooth into a higher grade gets surfaced as the production_blocker it actually is. That IS the doctrine working on its own creator. Earlier single-shot loops produced higher headline scores, which is why we shifted load-bearing measurement to consensus: less forgiving, more certifiable.