All Guides
Chief Architect · Operational Guide

Architect Playbook

Lens authoring, blocked PR triage, conformance review, and governing the agentic era.

Your weekly conformance review (20 minutes)

01

Navigate to /changecontrols/dashboard — check DCS for the week. Is it up, down, or stable?

02

For each pillar you own: check PCR. Any pillar below 85% deserves investigation this week.

03

Navigate to /changecontrols/designaudits — filter by BLOCKED status, this week’s date range. For each blocked PR: was this caught correctly (real violation) or a Lens misfiring?

04

For real violations: leave the block in place. The CHI auto-draft will surface it to the right person.

05

For misfiring Lenses: note it — update the Lens prompt via CHI before the next sprint.


Authoring an effective Lens

The quality of a Lens determines the quality of CDA. What makes a good Lens:

Specific and binary

The Lens prompt should produce a clear yes/no, not a spectrum.

Architecture-layer not code-layer

Evaluate structural intent, not implementation style.

Pillar-linked

Every Lens must be connected to a Pillar so conformance is attributable to a domain owner.

Testable

Before activating a Lens, mentally run it against 5 recent PRs — would it have fired correctly on all of them?

Navigate

Navigate to /steerings/lenses, click New Lens. Write the prompt, link to the pillar, set severity (BLOCKER for hard architectural rules, ADVISORY for guidance). Submit via Change Intention for approval.


Growing Governance Depth strategically

GD is not about quantity — it is about coverage. How to grow it well:

01

Review /changecontrols/designaudits monthly — what violation patterns are appearing that no current Lens catches? Those are your next Lens candidates.

02

Aim for at least 3 Lenses per Pillar (LPP ≥ 3). Check LPP per pillar at /steerings/lenses filtered by pillarId.

03

New Lenses should address real observed violations, not hypothetical ones. Evidence-driven authoring produces Lenses that stay active.

04

Deprecate Lenses that consistently generate false positives (high AFPR) rather than recalibrating indefinitely.


Handling a BLOCKED PR

When CDA blocks a PR, the workflow:

Step 1

Navigate to the blocked audit in /changecontrols/designaudits — read the finding. Is this a legitimate architectural violation or a miscalibrated Lens?

Step 2

(Legitimate violation) The CHI has been auto-drafted. Review it in /changecontrols/designaudits. If the change is architecturally sound, approve the CHI with conditions documented. If it is not, reject — the PR author must rework.

Step 3

(Misfiring Lens) Do not approve a CHI for a false positive. Instead, update the Lens prompt via a new CHI at /steerings/lenses. Until the Lens is updated, manually dismiss the finding on this specific PR with a note explaining the dismissal.

Step 4

Track your MTTCD. If blocked PRs are sitting more than 48 hours before you review them, your CHI review process needs a change — either more reviewers or a faster review cadence.


Governing AI agents with MCP

Your role in the agentic workflow:

01

Every agent session starts by querying rkito MCP for Ledger state, Lens criteria, and Steering context. The quality of what agents receive depends on how complete your Ledger and Lenses are.

02

GD is the agentic coverage metric: each active Lens is architectural intent loaded into agent context before code generation. Low GD = agents are coding with incomplete design constraints.

03

Review Agent Shepherd weekly to see which agent sessions queried your Lenses (MCPCAR). Sessions with high MCPCAR and clean CDA results prove that Lens authoring produces conformant agent output.

04

When LSCR is low (agents load Lenses but still fail): review the failing Lenses for prompt clarity. Lenses written for human review may need more explicit phrasing for agent use.


Quarterly: Steering artifact review

Four times a year, review the governance foundation:

01

Navigate to /steerings/dashboard — check SF (Steering Freshness). Any artifact not updated in > 180 days needs a review.

02

Check SCS — all 7 governance artifact categories should be present and active.

03

Review each Pillar’s PSI. A pillar with PSI > 180 days and declining PCR is silently failing.

04

Update artifacts that are stale. Deprecate via CHI anything that no longer reflects current intent.


Your role in Steering

Steering is your primary operational domain. You author and maintain the artefacts that govern every PR in the codebase. The quality and completeness of Steering determines the quality and coverage of the CDA pipeline.

/steerings/manifestos
Author and maintain the architectural Manifesto — the principles that all Lenses, Policies, and Pillars derive from. Review every quarter. The Manifesto is the source of authority when teams dispute a Lens decision.
/steerings/pillars
Create and own architectural Pillars — one per major domain (Security, Data, API Surface, Infra, Platform, etc.). Each Pillar is the container for that domain's Lenses, Policies, Best Practices, and Patterns. Monitor PCR per Pillar weekly.
/steerings/lenses + /steerings/prompts
Lenses are the named enforcement rules; Prompts are the binary invariant checks that evaluate PRs against each Lens. Author them together. A Lens name without a Prompt is never evaluated. A Prompt without a descriptive Lens name generates opaque CDA output that teams cannot understand.
/steerings/checklists
Author pre-PR Checklists for complex structural changes — the nuanced checks that cannot be expressed as a single binary Prompt. Checklists are advisory (developers self-certify), but they are tracked and visible in the CDA output.
/steerings/bestpractices + /steerings/patterns
Best Practices document how your organisation expects things to be built. Patterns document the approved structural solutions for common problems. Both are referenced by Lenses — a Lens can enforce that code follows an approved Pattern or meets a Best Practice.
/steerings/policies + /steerings/compliances
Policies are the architectural rules for your organisation. Compliances map external requirements (SOC 2, ISO 27001) to the Lenses that enforce them. You maintain these in collaboration with the CSO.
/steerings/blogposts + /steerings/announcements
Use Blog Posts for architectural decision narratives (why a Lens was introduced, what architectural shift a new Pillar represents). Use Announcements for operational communications — new Lenses activating, upcoming recalibration sprints, DCS trends.

The architect's Steering health signal: GD (Governance Depth) × SCS (Steering Completeness Score) × SF (Steering Freshness). All three must be healthy. A high GD with low SF means many Lenses that may be outdated. A high SCS with low GD means governance artefacts exist but are not machine-enforced.

Get started

Put your design intent into enforcement.

Author Lenses, track DCS and GD per sprint, and govern AI agent sessions with architectural context — before code ships, not after.