▸ Zone 3 of 4 · The Build

Come pressure-test the architecture

The further you go into Intent, the more you're looking at work-in-progress. This zone describes our current working architecture — three layers, four MCP servers, trust-scored autonomy, an OTel-native observability stack. Some of it is tablestakes hygiene. Some is our evolutionary hypothesis we're actively testing. Some is still open questions we don't have answers for yet. We've labeled what we can.

▸ Read this before going deeper

The pages linked from this section are the current technical substrate. Most were written before the 2026-04-09 multi-panel review that prompted this whole rebuild. They accurately describe what we're building, but they describe it in shipped-product voice rather than hypothesis voice. Where you see confident assertion, assume "this is our current best attempt, not a settled answer."

A full rewrite of the deep pages with hypothesis framing and maturity labels is scheduled for S1 (next week). For now: the content is current, the framing is one version behind. Read the panel review that prompted the rebuild →

▸ Architecture at a glance

L1

Compiled Knowledge Base Evolutionary

Everything the system knows — personas, journeys, decisions, domain models. Compiled once, kept current, not retrieved per-query. The Knowledge Engine product lives here.

L2

Transformation OS (the loop) Evolutionary

Notice → Spec → Execute → Observe. The four-phase loop that turns signals into agent-ready specs into observable execution into new signals. Domain-agnostic.

L3

Software Spec & Code Tablestakes

Executable specs with contracts. Running code. Event streams. TDD discipline applied to agent execution. The output layer.

Four MCP servers: intent-notice (signal capture, port 8001), intent-spec (spec authoring, port 8002), intent-observe (event ingestion, port 8003), intent-knowledge (compiled knowledge base, port 8004). 4-server topology is currently under review — see SIG-051 for the collapse-to-one-process spike.

▸ The imagery — go deeper into the diagrams

These are the rich visual artifacts from the v1.2 site. They describe current working architecture. Read them with the hypothesis framing in mind.

Architecture Overview

▸ Three-layer diagram

The full three-layer architecture page with the data flow diagram, 4-server topology, persona routing, and trust formula. Hero of the technical substrate.

v1.2 content · shipped-product voice · will be rewritten with maturity labels in S1

System Map

▸ Interactive SVG

Interactive signal-to-observation flow diagram. Click any node (MCP Server, Pipeline Stage, OTel Collector, etc.) to see detail panels. Shows the full capture→enrich→route→spec→execute→observe path.

v1.2 content · most visually rich page on the site · functional and current

The Loop Diagram

▸ SVG loop + phase cards

The canonical Notice → Spec → Execute → Observe loop with phase detail cards (inputs, outputs, tools) and loop property explanations. The visual you probably want if you only look at one diagram.

v1.2 content · clean visualization · current

Observability Stack

▸ OTel Mermaid diagrams

OTel-native stack architecture. Traces → Tempo, Metrics → Mimir, Logs → Loki, Dashboards → Grafana. Shows deployment phases, trace identity rules, cycle time histograms.

v1.2 content · schema is sound · runbooks and SLOs are open gaps (see backlog)

ARB & Tech Radar

▸ Radar SVG

Tech radar organized by Adopt / Trial / Assess / Hold. Shows which architectural choices we're committed to vs. experimenting with vs. rejecting. Also the ARB governance model.

v1.2 content · categorization needs review after 2026-04-09 findings

Architecture Decision Records. D1–D6 are the original tech choices (Markdown, Git, SQLite, etc.). D7–D19 are the three-layer architecture, Knowledge Engine split, spec-shaping protocol, federation, and the newly-added compilation/double-loop/origin-tracking decisions.

Historical D1–D19 set · upstream log consolidated to DEC-001 to DEC-014 (re-derivation pending)

Data Contracts & Schemas

▸ 25 event types + artifacts

Signal, Intent, Spec, Contract, Event schemas with YAML frontmatter definitions. 25 event types across the loop phases, the L0 approval gate, and system health (founding 15 documented in schema detail). The data substrate Intent runs on.

v1.2 content · missing the used_for/visibility/failure_type fields from Safety Contract Promise 1-4

Eight Claude Code subagents with model routing (Haiku/Sonnet/Opus), tool access, and the four-persona spec-shaping protocol (△ Shape / ◇ Outcome / ○ Contract / ◉ Readiness).

v1.2 content · missing the "Challenge the Intent" pass from SIG-050

Deployment

▸ Step cards + configs

FastMCP Cloud, local dev, platform comparison. Three-phase deployment: in-memory (current), persistent (planned), hosted (future). The honest labeling: Phase 1 is working, Phase 2 is specced, Phase 3 is aspirational.

v1.2 content · persistence is currently "Phase 4 later" which is one of the P0 issues

Subagent Definitions

▸ Agent cards

The eight subagents that run Intent: spec-writer, coordinator, context-resolver, signal-scorer, panel-reviewer (new), observer, tracer, knowledge-ingester. Each with tool scope and model routing.

v1.2 content · will be updated as panel-review skill ships in S1

▸ The hardening backlog (what we know needs fixing)

The 2026-04-09 ARB + Engineering panel review produced a consolidated P0/P1/P2 backlog. These items are architectural gaps we know about and are working on. They are not hidden; they are the honest current state. Full detail in SIG-051 on GitHub →

P0
SIG-022
Fix sequential ID collision — SIG-NNN / INT-NNN format will collide in multi-agent federation. Migrate to ULIDs or scoped prefixes (engagement-SIG-ulid).
P0
SIG-051
events.jsonl persistence — deployment page currently says "Phase 4: persistence" which means in-memory state dies on container restart. Move to SQLite+WAL with explicit fsync.
P0
SIG-051
Cross-engagement leak test in CI — Redaction at tool level (D11) is currently client-asserted. Add a test that attempts queries from engagement A and asserts zero B data.
P1
SIG-051
Runbooks and SLOs per MCP server — SLI definitions, error budgets, top-5 failure modes, diagnostic commands, escalation paths. Without these, "OTel-native" is a schema claim, not a capability.
P1
SIG-051
4-server topology spike — evaluate collapsing notice/spec/observe/knowledge to one process with 4 modules. ARB and Engineering panels both flagged as "accidental microservices-by-phase." Decision, not commit.
P1
SIG-051
Deploy-phase event family — add deploy.started / .completed / .rolled_back / incident.opened / .resolved. Without these, DORA metrics are a claim not a measurement.
P1
SIG-049
Safety schema fields — add used_for (trust scores), visibility (signals), failure_type (contract.assertion.failed). Enforces Safety Contract Promises 1-4 at schema level.
P2
SIG-051
Fitness functions in CI — layer dependency direction, schema conformance, cycle-time SLOs, contract coverage thresholds. Without these, "evolutionary architecture" is a slogan.
P2
SIG-051
Wardley map + cost model — one evolution-axis diagram, one dollar-cost-per-Intent-cycle page. Converts "AI collapsed implementation cost" from slogan to measurable.

▸ Pressure-test invitation

If you read the architecture pages and think we're wrong about something — about the topology, about the trust formula, about the observability stack, about the layer model — please tell us. We're actively looking for pressure-test feedback before the S1 rebuild.

Open an issue at github.com/theparlor/intent/issues → · or send a signal-style observation directly to the repo via PR against .intent/signals/external/

← Previous: The System Next: The Proof →