Revision 2 · 22 August 2026

A decision needs context it cannot invent, and it is worth nothing if it stays here.

Five Peers is a method layer and a record that sit above the assistant you already use. This page describes how both ends connect: the context that reaches the board, and the record that leaves it. Every block carries a status. Nothing here is unlabelled, and most of it is not built yet.

Live

Engine, not exposed

Stubbed

Specified, not built

Context in

What reaches the board

A board that only knows what you typed in two minutes is a board arguing about a decision it has never seen. These are the sources a real decision keeps referring to, what each one changes in the deliberation, and the exact scope it would require. None of them is connected today.

Calendar Specified, not built

What it reads: Who was in the room, how often the subject came back, and the date after which the choice is made for you.
What it changes in the deliberation: Cost of delay stops being rhetorical. The seat that prices waiting gets a real date instead of a feeling, and the pre-mortem gets a horizon.
Scope requested: Read: events and attendees on a named calendar, over a window you set. Never the body of an invitation.

Documents and drive Specified, not built

What it reads: The constraint already written down: a board pack, a shareholder agreement, a lease, a plan nobody reopened.
What it changes in the deliberation: Constraints stop being declared from memory. A constraint read from a document expires on a date instead of fading, which is exactly how the record treats it.
Scope requested: Read: named folders or documents you point at. No crawl, no full-drive index.

CRM and pipeline Specified, not built

What it reads: What this account already cost, what it already promised, and how many like it exist behind it.
What it changes in the deliberation: It answers the question the board asks about every single-client decision: what is this a case of? One account becomes a base rate.
Scope requested: Read: accounts, stages and amounts on a named pipeline. No contact exports.

Accounting and cash Specified, not built

What it reads: Runway, the shape of the burn, what the last three decisions of this kind actually cost.
What it changes in the deliberation: Reversibility becomes measurable. A door you can walk back through is not an opinion, it is a number of weeks of cash.
Scope requested: Read: aggregates and balances. No ledger lines, no payroll, no supplier detail.

Project and issue tracker Specified, not built

What it reads: Who already has the hours, what is late, and what this decision would displace.
What it changes in the deliberation: The execution seat stops asking who does this and starts naming the week it lands in. A decision that displaces nothing is usually a decision that changes nothing.
Scope requested: Read: open items, assignees and due dates on named projects.

Team channel Specified, not built

What it reads: Where the subject was last discussed, and by whom, without reading the thread.
What it changes in the deliberation: It feeds the seat that maps interests: who has a stake in this not being solved that way. Positions are usually stated in public long before they are defended in private.
Scope requested: Read: channel names, message counts and participants on channels you allow. Not message content, unless you point at a specific thread.

Record out

What leaves the board

This is the half most decision tools skip. A record nobody reads changes nothing, and an assumption nobody scheduled a review for is an assumption nobody reviews. The writes are deliberately few, and every one of them is reversible.

The decision note, where your team already reads Specified, not built

What goes out: The call, the reasons, the assumption it rests on, and what would make it wrong. Written into the document tool your company uses, as a document you own.
The rule: One scope, one destination, and the note carries a link back to the record. Deleting it in your tool does not delete the record, and revoking the scope stops the next write, not the past ones.

The review date, in the calendar that already rules your week Specified, not built

What goes out: Ninety days after the decision, an event that carries the assumption verbatim and one question: did it hold?
The rule: Write: one event, on a calendar you name. It is the only write that happens without you asking twice, because a review nobody scheduled is a review nobody runs.

The assumption, on the record it concerns Specified, not built

What goes out: When a decision is about one account, the assumption is attached to that account, so the next person who opens it inherits the reasoning instead of rediscovering it.
The rule: Write: one note on one object you designate. Never a field overwrite, never a stage change. The board proposes, your system of record stays yours.

Your board, inside the assistant you already use Specified, not built

What goes out: The five methods reachable from the assistant you have open, with the record behind them, so a decision does not require opening one more tab.
The rule: Straight answer on what a protocol buys you: it makes the record portable and the access standard. It does not make the thinking model-independent, because the orchestration still runs on our side. Anyone who tells you otherwise is selling you something.

MCP tool surface Specified, not built

The tool surface

Published to be argued with before it is built. Six tools, no more, because a surface that needs a manual has already failed.

Tool	Arguments	What it does
`decision.open`	`decision: string, context?: object`	Opens a decision and returns the framing, the missing information and the seats it would convene.
`board.compose`	`answers: object`	Returns the five methods composed for this person, with the reason each seat was taken.
`record.search`	`query: string, since?: date`	Searches the decision record: past calls, assumptions, outcomes, and what contradicted what.
`assumption.due`	`window?: days`	Lists the assumptions whose review is due, with the decision each one carries.
`outcome.close`	`decision_id: string, held: boolean, note?: string`	Closes the loop: the assumption held or it did not, and the record learns.
`note.push`	`decision_id: string, destination: scope`	Writes the decision note to a destination you have authorised, and returns the link.

Entities Live

The record schema, and why decay is per type

This is the one block on this page that is live: the graph below is emitted at the end of every composed board, then enriched at every decision session. Eight entity types, six relations in the active voice, a confidence score and a source on every node.

Entities: BoardDecision Assumption Constraint Value Observation Method Outcome
Relations: INFLUENCED_BY SUPPORTS CONTRADICTS RESULTED_IN WILL_TEST REVOKED (specified, not yet emitted)
Sources: user_stated inferred_from_* instrument_* composed_by_rule awaiting_review

Source on every entity: You can always tell what you said from what we inferred, and from what a rule composed.
Decay per type, not global: An assumption fades, half-life around fifteen months. An observation fades faster. A value does not decay at all: it is revoked by event. The REVOKED relation is specified for that and is not emitted by the engine yet. A constraint does not decay either: it expires.
The root is the board, not a decision: The constraints, values and assumptions set at composition describe how you decide, not one particular decision: they hang off the board. A Decision is born at each session and attaches to it.
Outcome is first class: Created the moment a decision is recorded, confidence zero, status pending, with a WILL_TEST edge to the load-bearing assumptions. At composition there is none: nothing is waiting to resolve yet. A record without outcomes is a write-only journal.

Real payload, cut to five nodes: the composition, then one session Live

{
  "schema": "fivepeers.decision-graph/v3",
  "entities": [
    { "id": "board_1",      "type": "Board",      "label": "Board de Atelier Vernon",
      "confidence": 1,   "source": "composed_by_rule",          "decay_lambda": 0 },
    { "id": "constraint_2", "type": "Constraint", "label": "Capital is the binding constraint",
      "confidence": 0.6, "source": "inferred_from_domain_risk", "decay_lambda": 0, "expires": "event_driven" },
    { "id": "assumption_3", "type": "Assumption", "label": "Acting on current information beats the cost of waiting",
      "confidence": 0.55,"source": "inferred_from_decision_style", "decay_lambda": 0.0016 },
    { "id": "decision_9",   "type": "Decision",   "label": "Whether to hire a Head of Sales now or wait",
      "confidence": 1,   "source": "user_stated",               "decay_lambda": 0 },
    { "id": "outcome_10",   "type": "Outcome",    "label": "(pending) result of this decision",
      "confidence": 0,   "source": "awaiting_review",           "decay_lambda": 0 }
  ],
  "relations": [
    { "from": "constraint_2", "type": "INFLUENCED_BY", "to": "board_1",      "confidence": 0.6 },
    { "from": "decision_9",   "type": "INFLUENCED_BY", "to": "board_1",      "confidence": 1 },
    { "from": "decision_9",   "type": "RESULTED_IN",   "to": "outcome_10",   "confidence": 0,
      "status": "pending", "review_due_days": 90 },
    { "from": "outcome_10",   "type": "WILL_TEST",     "to": "assumption_3", "confidence": 1 }
  ]
}

Governance

Permissions, and what we will not do

Read-only by defaultA connector arrives with no write scope at all. Writing is granted per destination, never per source, and it is granted by you rather than by an administrator you have never met.
One scope, one purposeA scope names a source, a window and a purpose. There is no scope that means everything, and a scope that cannot be described in one sentence is refused.
Revocable, and honest about itRevoking a scope stops the next read and the next write. It does not unwrite what was already written into your own tools, and any product that tells you it does is lying about how the internet works.
Traced on both sidesEvery read and every write leaves a line: what, when, which scope, for which decision. That trail is part of the record you export.
The record is yoursOpen format, published schema, export on demand. Hosted in France. The methods can be copied in an evening; the record is the part that gets hard to replace, and it does not belong to whichever model you use this year.

The engine Engine, not exposed

The engine routes that already exist

These are real, they are in the repository, and they are not exposed on the internet. The engine has never run against a live model: everything green about it is green against a deterministic simulator.

Method	Route	What it does
`GET`	`/health`	Engine liveness.
`GET`	`/memory`	The record for one executive.
`GET`	`/outcomes/pending`	Decisions whose outcome is still open.
`GET`	`/profile`	The composed board and how it was composed.
`POST`	`/boards/compose`	Composes the five seats from answers.
`POST`	`/decisions/deliberate`	Runs the deliberation: blind pass, then attack.
`POST`	`/decisions/commit`	Commits the decision and its assumption.
`POST`	`/outcomes/relance`	Reopens an assumption whose review is due.
`POST`	`/decisions/outcome`	Records whether the assumption held.

FAQ

Questions we get, answered without marketing

Does Five Peers read my data today?

No. Nothing on this page reads a single external source today. The connector surface is specified and published so it can be argued with before it is built. What runs today is the composition of the board, in your browser, and the record written at the end of an onboarding.

What is MCP, in one paragraph?

A standard way for an assistant to reach tools and context. Instead of one integration per assistant, a tool exposes its capabilities once and any compliant assistant can use them. For a decision layer it matters twice: it is how context reaches the board, and it is how the board reaches you where you already work.

Why would a decision tool need write access at all?

Because a record nobody reads changes nothing. A decision that stays in our interface is a decision your team never sees, and an assumption nobody scheduled a review for is an assumption nobody reviews. The writes are deliberately few: a note, a review date, an annotation on the object concerned.

What happens to the record if I leave?

It exports in an open format, and the schema is published on this page. That is not a courtesy, it is the point: the methods can be copied in an evening, the record cannot, and a record you cannot take with you is a record you do not own.

Does connecting sources make the answers better, or just longer?

Unproven, and we will not pretend otherwise. The claim we are willing to defend is narrower: a constraint read from a document does not decay like a constraint recalled from memory, and a cost of delay with a date behind it is arguable while a feeling is not. Whether that produces measurably better decisions is exactly what the test described at the bottom of this page is meant to settle.

Which assistants are targeted?

Any assistant that speaks the protocol. We are building against the ones our users already have open rather than picking a side, because the record is meant to outlive whichever model you use this year.

Where is the data hosted?

The decision record is hosted in France. The deliberation itself calls a model, and we will not claim that everything stays inside a border when it does not: the page that describes what we do not claim says so in the same words.

Can I use the record without the board?

That is the intent. The record is a primitive with three consumers: the session that writes it, the review that reopens it, and whatever you build on the export. If only the third one survives, the record was still worth building.

What we do not claim

Hold us to this page

Every claim here carries a status because a specification without one is a brochure. If a block says specified and not built, it means no line of code exists. When that changes, this page changes first, and the revision date at the top moves.

Start with a decision you are actually facing