~/openarch/work/decisionos-// case study

DecisionOS

A decision intelligence platform - the system of record for how an organisation decides, not only what it decided. Decisions carry their context, the options weighed, and the rationale that would otherwise leave with the meeting.

OpenArch · in-house platform·decision intelligence · org analytics·2026·in maintenance

openarch.in/work/decisionos

//the brief

What we built.

Most companies can tell you what was decided and almost none can tell you how. DecisionOS makes the decision itself the record: who is accountable, who was consulted, what was rejected and why. RACI is not a diagram here - it drives routing, notification and escalation, and doubles as the permissions model. The analytics layer reads that trail to surface decision debt and bottlenecks, and Compass answers questions about the org strictly from what the trail can support.

// How the call got made.

domaindecision intelligence

shapeorg platform

statusin maintenance

lineagecord → brain

stack

reactnode · expresssupabase · postgressocket.iogrok · llama-3.3-70b

//what we shipped

Decisions as records

Title, context, options considered, stakes and deadline - closed out with an outcome and the rationale behind it, not just a status flip.

RACI routing

One accountable decider, an advisor set that must be consulted, and an informed list. The same structure decides who is notified and who can see the record.

Escalation and delegation

Decisions past their deadline escalate rather than rot quietly, and delegation moves accountability explicitly instead of by inbox.

Org health

Decision debt, bottleneck deciders, velocity trend and department comparison - computed from the trail, written back nowhere.

Decision intelligence score

A per-decision score over how well a call was framed, consulted and evidenced, so quality is inspectable rather than felt.

Compass

A strategic-consultant surface answering in the second person about this organisation. Grounded in retrieved org state, and explicit when the state is too thin to answer.

//data model

schema.sql5 tables

table decisions

title, context, type, stakes, status, options, decider_id, deadline

table decision_advisors

decision_id, user_id - the consulted set

table decision_informed

decision_id, user_id - the informed set

table org_hierarchy

user_id, manager_id, department, org_id

table notifications

user_id, decision_id, kind, read_at, created_at

// decision status machine

01draft
02pending
03decided

//business logic

accountable.tsExactly one accountable

// Zero or many accountable owners is a data-integrity bug,
// not a UI edge case - a decision nobody owns never closes.
function assertAccountable(decision) {
  if (!decision.decider_id) {
    throw new IntegrityError('decision has no accountable owner')
  }
}

compass.tsAnswer only from state

// Compass never invents org facts. Thin state gets said out
// loud rather than filled in with plausible management-speak.
function answer(question, orgState) {
  if (!orgState.sufficientFor(question)) {
    return cannotSee(question, orgState.gaps())
  }
  return compose(question, orgState).withCitations()
}

//on the roadmap

Honest edges.

→Retiring Cord-era identifiers without a rename that buries real diffs
→Upstream capture for metrics the read-side analytics layer cannot derive
→Wider retrieval for Compass where org state is too thin to answer

//result

accountable owner per decision

writes from the analytics layer

states in the decision machine

The trail is the asset, so decision records are append-only in spirit and deletes are soft - status changes and rationale edits are history rather than overwrites. The analytics layer is strictly read-side: when a metric needs data that isn't there, the fix is upstream capture, never a computed column written back over the record.

all_work // next buildMarquiseThe paper form, kept honest.