Review a change without making it live
Support status: Supported preview
Imagine that your organisation has an accepted compliance policy. Two changes are being considered at the same time: one is ready for a reviewer, while the other has already been approved but has not yet been put into effect.
OntoGraph can show what is accepted now, what may become accepted next, and the exact governance step separating the two.
The question
Which policy is actually in force, and what must happen next for each proposed change?
In an ordinary system, all three records might be reduced to labels such as
active, pending, or approved. That loses the difference between evidence,
review, authorization, and the event that actually changes current state.
What a person sees
The evidence-backed result is precise:
- Version 1 remains the accepted state.
- Proposal A is ready for review.
- Proposal B is ready for promotion.
- Proposal B has no promotion record.
Approval therefore gives Proposal B permission to advance; it does not pretend that the advance already happened. OntoGraph derives current state from the latest promotion record instead of a mutable status field.
Why this is useful
| Benefit | What it prevents |
|---|---|
| Draft safety | A proposal cannot silently become the organisation's accepted position merely because it exists. |
| Clear next action | Reviewers can distinguish “needs review” from “approved and awaiting promotion.” |
| Explainable authority | A current version can be traced through its proposal, decision, change set, actor, and promotion. |
| Preserved history | Proposed and accepted states remain visible together instead of overwriting one another. |
The lifecycle in plain language
Accepted Version 1
│
├── Proposal A ── validated ── ready for review
│
└── Proposal B ── reviewed ── approved ── ready for promotion
│
└── not current until promoted
The names “Compliance policy,” “Proposal A,” and “Proposal B” are presentation aliases for the canonical fixture ids. They make the story readable but do not rename or create canonical records.
What this proves
For the bounded memory/file Developer Preview, the runtime can return accepted package state beside selected proposed states, calculate their distinct governance readiness, and preserve Decision and Promotion as different things.
Follow the executable evidence:
- Executed human questions and evidence checks
- Accepted versus proposed state
- Governance stage readiness
- Current promoted state
Each reference page contains the authoritative fixture path and digest, exact request and expected output, execution engine, and verified runtime result.
What this does not prove
This page explains deterministic read-model evidence. It does not create canonical truth, semantic adoption, review approval, a governance decision, promotion, model certification, release authority, or backend-specific equivalence.
The example does not claim a production multi-user service, a general query language, or equivalence for Neo4j, Dgraph, SQL, RDF, or another backend.