The Decision Graph
This remembers why.
Every system you run remembers what happened. None of them remembers why you decided — what the evidence was, which causes were weighed, what policy allowed, who approved, what was done, and whether it worked. The MIZ OKI Decision Graph exists to remember exactly that.
Definition
What is a Decision Graph?
A Decision Graph is an operating model, not a storage model. Storage systems answer "what do we know?" A Decision Graph answers "what should we do, are we allowed to, who says so, and did it work?" — and keeps every one of those answers connected to the evidence that produced it.
- Evidence
- Context
- Decision
- Outcome
- ↺ back to Evidence
Honest comparisons
What each structure does well — and where it stops
None of these technologies is wrong. Most organizations should keep all of them. Each simply answers a different question, and none of them was built to answer the decision question.
| Structure | Does well | Where it stops |
|---|---|---|
| Data warehouse | Retains complete history, durably and queryably. The system of record for what happened. | Stores facts, not decisions. It cannot say why an action was taken, who approved it, or what was predicted. |
| Semantic layer | Gives metrics consistent definitions so "revenue" means one thing everywhere. | Defines measures. It carries no causes, no policies, no approvals, no outcomes. |
| Knowledge graph | Organizes entities and relationships — what is connected to what. | Explains connections, not decisions. It has no native concept of authority, veto, or predicted-versus-realized. |
| Vector database | Finds semantically similar content fast. Excellent recall over unstructured material. | Similarity is not causality, and retrieval is not governance. Nothing in it is accountable. |
| Agent memory | Lets an AI agent carry context across steps and sessions. | Private to the agent, rarely inspectable, and not an organizational record anyone can audit or replay. |
| Decision Graph | Preserves the complete lifecycle of every decision: evidence, context, reasoning, policy, approval, action, and realized outcome — connected, inspectable, replayable. | It complements the others rather than replacing them: warehouses keep the facts; the Decision Graph keeps the decisions. |
What makes it an operating model
Six properties, all load-bearing
Temporal memory
Every fact carries when it was known, not just when it happened. The graph can answer "what did we know at the moment we decided?" — the only honest basis for judging a past decision.
Provenance
Every observation carries its source, its quality, and its identity resolution. Evidence you cannot trace is evidence you cannot govern with.
Causal relationships
Edges carry claims about cause, each with supporting and disconfirming evidence attached — so "latency caused the abandonment" is an inspectable assertion, not a caption.
Approval history
Every decision records the authority that made it: the named approver, the delegated rule, or the automation grant — and every veto is preserved alongside every approval.
Replay
Any decision can be re-walked end to end: the evidence as it stood, the alternatives considered, the checks applied, the authority invoked, the action taken, the outcome realized.
Continuous learning
Predicted and realized outcomes are compared on every decision, and the difference adjusts future confidence and weighting. The graph gets harder to fool over time.
One record, end to end
Walk a single decision record
This is what "remembering why" looks like in practice — one worked decision record, layer by layer. Expand each entry. Illustrative
EvidenceBlended CPA moved sharply; conversion slipped; creative engagement held steady.
Observations from the media, commerce, and experience streams, each stored with source, timestamp, provenance, and quality. The CPA movement is recorded as an observation with its detection threshold — not as an alarm someone happened to notice.
ContextThe movement resolves to real things: two campaigns, one landing path, one hero SKU.
The graph binds the observations to the entities they concern and the constraints that govern them — the margin floor on the SKU, the budget ceiling on the campaigns, the objective this quarter actually carries.
ReasoningFour causes tested; two survive the evidence.
Creative fatigue is ruled out by stable engagement. Tracking failure is ruled out by server-side verification. Landing-page degradation and an inventory constraint survive — and both the surviving and eliminated hypotheses are preserved with their evidence.
PolicyCandidate actions checked against the margin floor and the budget-shift ceiling.
Each candidate action — rebalance, pause, hold — is validated against configured financial and brand policy. One candidate breaches the margin floor and is vetoed; the veto is recorded with the exact check that failed.
ApprovalThe surviving recommendation routes to the named owner; nothing moves before authorization.
The recommendation crosses the autonomous ceiling, so it routes to the accountable human — with the full record above attached. The approval, its time, and its authority basis are written into the same record.
ExecutionThe approved action dispatches — scoped, bounded, reversible, logged.
Only the authorized change is made, with its scope and rollback path recorded before dispatch. If the decision had been "hold", the hold would be recorded with the same rigor.
OutcomePredicted versus realized — scored, not assumed.
The realized result is compared against the prediction stated at decision time. The difference adjusts confidence for this class of action, and the whole record — evidence to outcome — remains replayable.
Every layer of this record is inspectable after the fact. That is the difference between a system that acted and a system that can explain itself.
Next
See the graph make a decision
The lifecycle that writes these records — sense, reason, plan, validate, decide, act, learn — stage by stage, with an interactive walkthrough.