System description — the full platform, end to end

How to read this document. This is the discovery report for the whole platform — deliberately describing the optimal end state, not the current build. Read it as one journey: an engagement travels from first contact to a living system in operation, and each station names the capabilities that serve it and embeds the user stories that define it. Items marked proposed are exactly that: this document is the scoping instrument — confirming an item puts it in scope, rejecting it keeps the system honest. Current build status is stated plainly at the end. Detail lives elsewhere by design: agreed scope in the Scope document, architecture in Solution, the near-term plan in Delivery plan.

Who it is for. Three actors, one record. The consultant runs engagements and reviews everything; the client answers, accepts and watches — full visibility, gated editing; agents draft, build and report — proposing always, deciding never.

1 · An engagement begins

Setup is a choice of profile, not a week of project hygiene. The engagement scaffolds exactly the documents its profile owes, the gap analysis runs from minute one, and both the intake address and the client link exist before the first workshop.

SCN-10 — Engagement setup and tailoring (proposed)

The five minutes that replace a week of project setup. Creating an engagement selects its profile; the platform scaffolds exactly the documents that profile owes — empty sections, live gap analysis — and nothing more.

SCN-19 — Material arrives by mail (proposed)

The lowest-friction intake there is: the client forwards a thread to the engagement's address; it files as a source; agents cross-reference and propose — enrichments, contradictions, new clarifications.

2 · Discovery — from raw material to agreed scope

The platform's founding wedge, live today: intake becomes proposed items with sources and confidence; unknowns become clarifications; the consultant reviews in the document, not in a chat; readiness is computed. The full flow is specified in the Scope document (intake and review-workspace sections) — this journey continues where discovery ends.

3 · Agreement — scope becomes something both sides can hold

Review rounds carry documents to the client where they live; answers and acceptances flow back; the baseline is rendered, signed, and legally anchored to an exact snapshot. From then on, change is arithmetic: requests carry blast radius and lifecycle, and nothing changes silently.

SCN-20 — A review invitation reaches the client where they live (proposed)

Rounds don't wait to be discovered. Opening one sends the invitation (mail first, chat later) with the magic link; reminders pace themselves from answer-latency telemetry instead of nagging.

SCN-21 — A baseline is signed (proposed)

The legally clean anchor: the rendered baseline document is e-signed by both sides; the signature binds to the exact release snapshot — nobody ever argues about which version was agreed.

SCN-13 — A change request after the baseline (proposed)

The client asks for something new once scope is signed. The platform turns the ask into a change request with computed blast radius, a real lifecycle, and — on approval — a scoped diff onto the next baseline. Change control the original methodology priced with 26 factors, reborn as arithmetic. The original methodology's discipline carries over: scope creep is countered by swapping priorities, not by add-only — an approved CR invites the question 'what moves out to make room'.

4 · Design — the same discipline, one level deeper

Design documents draft from confirmed scope per the content specs, get reviewed internally, then meet the client in a round — ending in a design baseline that build cuts from.

SCN-11 — Design is reviewed with the client (proposed)

Discovery's sibling for the design phase. Agents draft the solution and integration documents from confirmed scope; the consultant reviews internally; a review round carries the design to the client; acceptance becomes the design baseline.

5 · Build — agents under governance

Coding agents receive compiled briefings, build in their own runners, and cannot merge against the record: deviations from decisions are caught before they land, and every session leaves receipts. Acceptance is a diff — delivered against scoped — not a demo and a handshake.

CAP-7 — Build governance (proposed)

Coding agents build increments under the platform's rules: briefed from the record, checked against decisions and constraints before anything merges, and their receipts — what was built, tested, deviated — written back as items. External pipelines (ForgeDock-style issue-in/PR-out) can run as engines underneath: governed, never autonomous.

SCN-12 — An increment is built under governance (proposed)

Where the platform's promise meets code. An increment is cut from the baseline; coding agents receive compiled briefings per task; deviations from decisions are caught before merge; receipts land as items; acceptance diffs delivered against scoped.

6 · Acceptance, go-live, and life in operation

The client accepts scenario by scenario; the go-live checklist computes from what the profile owes; then the version lives — incidents in its own stream with SLA clocks, small changes as CRs, while the next version is scoped in parallel on the same record.

SCN-14 — Acceptance and go-live (proposed)

The formal close of a delivery stream. The client walks the scenarios and accepts per item; the go-live checklist computes from the catalog (which ops documents this profile owes); the live baseline is marked and the ops stream opens.

SCN-15 — An incident in the ops stream (proposed)

Production hurts; the record absorbs it. Incidents arrive by mail or form into the live version's stream, linked to the scenarios they break, with SLA clocks measured — and fixes that change scope become CRs, not folklore.

7 · The provider's view — many engagements, one morning

CAP-8 — Operations & portfolio (proposed)

Life after go-live, and life across engagements. Each live version runs as its own stream — incidents, small changes, SLA telemetry — while the consultant's portfolio view shows every engagement's queues, drift alarms, aging clarifications and waiting clients in one morning glance.

SCN-16 — The consultant's portfolio morning (proposed)

One glance across every engagement: which queues rot, which clients are silent, which streams drift. The platform turns five engagements from five anxieties into one prioritized list.

8 · The record that onboards its own people

The deepest promise: the engagement can onboard its next consultant — human or agent — without the previous one's head. And the methodology itself is content: it versions, releases, and is adopted deliberately.

SCN-17 — A new consultant or agent onboards from the record (proposed)

The two-consultants problem, solved structurally: the next person (or session) reads vision, scope, solution and plan, receives a role-based compiled brief, and is productive without a handover meeting — because the record, not anyone's head, holds the engagement.

CAP-9 — Foundation manager (proposed)

The methodology itself as living, versioned content: catalog, content specs and rules edited and reviewed like any document, released as foundation versions that engagements adopt deliberately — so improving the method improves every future engagement without silently changing running ones.

SCN-18 — The methodology evolves without breaking engagements (proposed)

A lesson learned becomes a spec change, reviewed like any document, released as a foundation version — and running engagements adopt it deliberately instead of being silently rewritten.

Integrations — where the platform touches the world

Deliberately few, all at the boundary: git (repo emission of generated views; build governance reads pipelines) · mail (intake addresses in, invitations and reminders out; chat channels later) · e-signature (baselines) · agent runners (briefings and receipts over MCP; external pipelines like ForgeDock as governed engines) · nothing else until an engagement forces it.

Information architecture in one paragraph

One record of typed items with lifecycles, revisions and links; documents are items whose prose embeds other items, so narrative can never contradict truth; releases pin versions (review rounds and baselines); increments stream parallel work; the methodology lives above engagements as versioned foundation content; and every surface — consultant workspace, client link, agent briefing, repo markdown — is a rendering of the same record.

Status and roadmap

Built and live: the record, discovery scoping on ourselves, documents with embeds and the reader, releases/baselines/diffs, comments, telemetry events (INC-1 closed, INC-2 active). Next, in order: review actions with consultant login and the digest (finishing INC-2) · the client loop: invitations, rounds, accept/comment, uploads (INC-3) · intake agents and mail-in (INC-4) · build governance and briefing compiler in anger (INC-5) · ops streams and portfolio (INC-6) · foundation versioning and repo emission (INC-7) · then engagement #1 with a real client measures everything. Pricing and provider multi-tenancy stay deliberately parked.