The whole thing, end to end
How a signal becomes a decision.
For: anyone who wants the whole picture in one read
If you read only one page, read this one. Cardinal and its agent ring exist to do one thing well: turn the daily storm of incoming signal into a small number of decisions a human actually makes — and to keep an honest record of how each one happened. Here is that journey, start to finish.
The two halves of the work
Every engagement generates more signal than any one person can read — hundreds of messages, meetings, backlog changes, and documents a day. Cardinal splits the work in two. The agents scan it all and metabolise it into structured artifacts. The humans make the decisions that carry weight. The database is the contract between the two halves: the agents write to it, the humans act through it, and neither side can change the record without leaving a trace.
What the agents do
- Watch every inbound channel (read-only)
- Group, classify, and summarise the noise
- Draft briefs, decisions, risks, and replies
- Stage outbound for a human — never auto-send
What the humans do
- Read a short, ranked picture instead of the firehose
- Make the load-bearing calls (Approve, Ratify, Publish)
- Assign owners and check work off
- Decide what reaches the customer
A signal's journey
Follow one inbound signal — say, a customer email that hints at a new risk — from the moment it arrives to the moment a human has acted on it and the record is sealed.
sequenceDiagram
autonumber
box rgb(254,243,199) The world
actor Src as 📨 Customer email
end
box rgb(220,252,231) Read-only sensor
participant Sc as 🔭 Scout
end
box rgb(241,245,249) System of record
participant DB as 📚 Database
end
box rgb(219,234,254) Peer ring
participant CoS as 🤖 Chief of Staff
end
box rgb(252,228,236) Human
actor Op as 🧑✈️ Operator
end
box rgb(237,233,254) Delivery
participant Out as 📤 Channel
end
box rgb(31,41,55) Audit
participant Ch as 🔗 Chain
end
Note over Src,Sc: 1 · ARRIVE — a scout harvests it
Src->>Sc: a hint of new risk
Sc->>DB: stage signal (read-only of source)
DB-->>Ch: 🔒 append
Note over DB,CoS: 2 · METABOLISE — next ring-tick
DB->>CoS: 1 unprocessed signal
CoS->>CoS: classify · group · draft a risk
CoS->>DB: stage draft risk + rank for brief
DB-->>Ch: 🔒 append
Note over DB,Op: 3 · DECIDE — morning brief
DB->>Op: 5-3-2-1 brief (top item: this risk)
Op->>DB: ratify · assign owner
DB-->>Ch: 🔒 append
Op->>DB: press Publish to customer
DB-->>Ch: 🔒 append
Note over DB,Out: 4 · PUBLISH — agent-dispatched
DB->>Out: queue per-target delivery
Out->>Out: render · send · await ack
Out-->>Ch: 🔒 append
Note over Ch: 5 · RECORD — every step sealed in the chain
Every arrow that writes anything passes through the same audited write-path — see the golden rule below.
Arrive — a scout harvests it
Signal enters through whatever channel it lives on — an inbox, a chat, a backlog, a pipeline. A scout — one of a family of narrow, read-only readers — notices the new item and drops a short summary into a single signal inbox table. The scout never changes the thing it is watching, never sends anything, and never spawns helpers. Anything sensitive is routed for review rather than ingested.
Metabolise — the ring makes sense of it
The Chief of Staff reads the signal inbox and turns the noise into structure. Related messages are grouped; the important few are distilled into a twice-daily 5-3-2-1 brief — five risks, three decisions, two customer signals, one fire — plus a queue of drafted outbound and a watch-list of things going quiet. Our example email becomes a drafted risk with a proposed owner, waiting for a human.
Broad & shallow
The Chief of Staff scans everything but holds nothing deeply. When a signal needs real architectural thought, it routes the item to the Solution Architect rather than reasoning about it itself.
Deep & narrow
The Solution Architect picks up routed items that need a decision — authoring an ADR through review and compliance gates, one careful decision at a time.
Decide — a human acts in Cardinal
This is the hinge of the whole system. The human opens Cardinal — the web app — and sees the ranked picture the agents prepared, not the raw firehose. They make the calls that matter: approve a draft, ratify a decision, assign an owner, check work off, or decide that something is ready to go to the customer. Our drafted risk gets an owner and is accepted.
Publish — it reaches the world, on purpose
Once a human approves something, it can be published — pushed out to one or more destinations. A decision might go to the work-item tracker and to the customer; a report might go by email; a status might go to a shared notebook. Publishing is always a deliberate, human-pressed action, and a single artifact can go to several targets at once.
Record — the chain remembers
Every step along the way — the scout's harvest, the brief, the human's decision, the publish — wrote a row to a hash-chained audit trail. Each row is linked to the one before it, so the record is tamper-evident: you cannot quietly rewrite history without breaking the chain. The Steward verifies the chain, attests every shipped change, and raises the alarm if reality and the record ever disagree.
The golden rule that makes it all hold
One rule underlies everything above: data is never written by a raw insert. Every write — whether it comes from an agent or from a human clicking in Cardinal — goes through a stored procedure that checks who is writing, makes the write idempotent, and appends a hash-chained audit row. The agents and the app use the same procedures. That is why the two halves stay consistent, and why the audit trail is trustworthy.
Right actor
Each write declares whether it came from a human, an agent, or an automated cadence — and the procedure enforces it.
Idempotent
A retried write doesn't double-apply; the same logical action lands once.
Audited
Every write appends a tamper-evident row. The chain is the system's memory.
Go deeper: the data model & write-path → · Meet the agents →