The Cardinal application

The human's window.

For: anyone who wants to know what the app does

Cardinal is the web application the human uses to run an engagement. Where the agents work in the database, the human works in Cardinal — reading the picture the agents prepared and taking the actions that carry weight. This page is what the app is and who uses it; see Frontend and Backend for how it's built.

Read the picture Take the load-bearing actions Same database as the agents

Who uses it, and for what

The operator

The human lead. Reads the briefs, approves drafts, ratifies decisions, assigns owners, checks work off, and decides what reaches the customer.

The delivery team

Reviewers and contributors who view engagement state and take the actions in their remit — through the same audited surface.

The human actions are the point. Publish, Approve, Ratify, Check-off, Assign — these load-bearing actions are exactly the things an agent is not allowed to do on its own. Cardinal is where they happen.

A map of the pages

Each page in the app reads (and writes through) one family of records in the system of record.

Page	What it shows / does
Overview	Engagement health, latest activity, headline counts, and cost at a glance.
Conversations	Auto-grouped inbound and outbound message threads.
Workstreams	Workstream tracking with a state machine.
Decisions	Decision records and their lifecycle; assign an owner; publish.
ADRs	Architecture Decision Records through review and compliance gates.
Risks	Risks, issues, and blockers with severity and owners.
Documents	The sensitivity-gated document library.
Reports	Generated reports with a red/amber/green status; edit and export.
Publications	The outbound delivery board: awaiting acknowledgement, rejected, drafts.
Audit	The hash-chained audit trail viewer.
Metrics	Cost and activity charts.
Settings	Engagement-level settings.

How the front end is built → · The records behind the pages →