Roomcord / Decision ledger
Keep the decision. Keep the reason. Keep the changes.
A project moves on, but its agreements still matter. We’re building Roomcord’s decision ledger so a team can find the decision, its reasoning and the source without reconstructing the meeting. AI proposes the record. People confirm what was agreed.
What is a decision ledger?
A decision ledger is a searchable record of decisions and their reasoning. It connects what was agreed, who approved it, when, why, which options were rejected and the supporting evidence. Roomcord’s developing ledger is for project owners and leaders who need to understand an agreement later, including what changed and who confirmed the change.
The ledger is the memory of the decision workflow. Conversations supply the context, suggested cards structure it, people confirm the record, ballots resolve the choice, and accepted commitments carry it into delivery. Follow-up and closure add evidence to the same history.
A decision is different from a recap or a task
| Record | Main question | What belongs in it |
|---|---|---|
| Meeting recap | What did we discuss? | Discussion, open questions and next steps. |
| Decision entry | What did we agree, and why? | Chosen option, approver, date, rationale, alternatives and sources. |
| Commitment | Who will deliver what, by when? | One accepting owner, promised date, first step and completion evidence. |
A recap can contain a proposed decision. It does not prove approval. An approved decision can create several commitments, each with its own owner and date. The ledger should distinguish decision closure from completion of the resulting work.
Build a record people can check
- Capture the proposed agreement. AI extracts a possible decision from the room and keeps the supporting quote and exact source location, such as a message or recording moment.
- Resolve missing details. If the approver, date or rationale is unclear, mark it unconfirmed and ask. A model’s plausible explanation is not the team’s recorded reason.
- Confirm the decision. The designated people review the proposal and ballot result. Protected financial, legal and people decisions retain their required approval; an AI suggestion cannot stand in for it.
- Connect the commitment. Link the accepted work, owner, due date and first step without treating an approval as automatic acceptance of an assignment.
- Retain amendments and closure. Attribute changes, preserve the earlier agreement and attach the evidence of the revised decision or completed work.
Illustrative record: a launch decision and its amendment
Fictional example of the intended workflow, not a customer result or released interface. The source references below are example labels, not working links.
| Field | Confirmed decision D-014 |
|---|---|
| Decision | Launch the reporting feature to the pilot group on November 6, 2026. |
| Approver and decision date | Maya, project lead, October 27, 2026. |
| Why | The pilot scope is testable; wider rollout needs further validation. |
| Options rejected | Wider rollout on November 6; postponing all access until December. |
| Sources | Example room message M-208; example meeting recording at 12:40; Maya’s approval M-214. |
| Delivery commitment | Alex accepts pilot preparation by November 4; first step: confirm the test checklist. |
| Open information | Pilot test result is not yet available. |
October 30 amendment: a failed test prompts a new proposal to move pilot access to November 13. The AI marks the new date as suggested. Maya approves the revised decision in example message M-239, and Alex separately accepts preparation by November 11. The history retains the November 6 decision, the test evidence, the changed rationale, Maya’s confirmation and Alex’s revised commitment.
After preparation is delivered, its evidence closes the commitment. Pilot access still needs its own delivery evidence. Neither the date change nor an AI recap establishes that the launch happened.
Find company memory within the right boundaries
The intended ledger lets authorized readers find decisions by room, topic, owner, date or status and open the underlying evidence. Cross-room discovery must respect access to the room and its sources. A search result should not expose a restricted discussion to someone who cannot read it.
The ledger supports a shared understanding; it does not guarantee that people will never disagree or serve as a claim of legally immutable storage. If sources conflict, show the conflict and request clarification. If the reason was never recorded, say so. Later explanations should be attributed as later additions.
Keep the decision connected to the work
See how approval ballots resolve a proposed choice, how commit and chase follows accepted work, and how boss view surfaces pending decisions and delivery exceptions. The Roomcord overview explains the complete decision engine.
Roomcord is the product where the team shares the agreement. Bewize Hub and Wize Browser are supporting components, rather than separate records the team must reconcile.
Availability as of October 21, 2026
Rooms, chat, files and meeting capture are the existing foundation for shared context. The formal decision ledger, structured decision history, permission-scoped discovery and links through ballots and commitments described here are part of the decision engine we are developing. This page announces the intended experience. It does not claim generally available ledger functionality or released ledger exports. Confirm availability and evidence access for your first room.Start with an agreement your team keeps revisiting
Choose one recurring decision and identify its approver, rationale, source and resulting commitment. Agree who may read the record and how amendments are confirmed. Review a sample against the original discussion: can someone explain both the decision and the reason for its latest change?