A bounded governance calculus over graph state

OntoGraph is not merely storing nodes and edges. Within its current bounded scope, it represents semantic and governance facts as distinct typed records, applies explicit invariants, and derives answers that preserve the path from source evidence to accepted state.

That makes the current product usefully describable as a bounded governance calculus over graph state.

Here, calculus means a small system of typed inputs, invariants, derivation rules, and inspectable results. Bounded means only the object families, validation rules, query contracts, and memory/file behavior explicitly proven by the Developer Preview. It does not mean that OntoGraph can calculate truth, replace institutional authority, or model every possible governance system.

The essential derivation

The governing idea can be written compactly as:

Current(package) = targetVersion(latest valid Promotion for package)

This is pedagogical notation, not a new canonical object definition. In the current executable contract, targetVersion means the Promotion's toVersionRef. “Valid” means applicable within a canonical graph that has already passed the relevant structural and semantic validation; the query does not manufacture validity or authority.

For the current memory/file implementation, the read path is deterministic:

1. Select Promotion records whose targetPackageRef is the requested package.
2. Order them by promotedAt, with canonical ID as the deterministic tie-breaker.
3. Select the latest record and hydrate its Proposal, Decision, ChangeSet, previous Version, and target Version lineage.
4. Derive current state from its toVersionRef.
5. Require the package's active Version records to include that target.
6. Return the derivation and its references as currentStateProof.

If the package has no Promotion, there is no promoted state to return. If its active Version disagrees with the latest Promotion target, the query fails closed instead of silently trusting either representation.

The executable result therefore does not merely say “Version 1 is current.” It can exhibit why:

Proposal
  -> approving Decision
  -> Promotion event
  -> target Version
  -> active-Version agreement

See the executed accepted-versus-proposed query and current promoted-state query for the exact records and returned proof fields.

Why three tempting alternatives are wrong

Not the highest version

A version label orders names according to some convention. It does not prove that an authorized governance event made that version current. A package can contain a higher-numbered draft, rejected candidate, or historical import without accepting it.

Not approved=true

Approval records a deontic fact: an authorized decision permits a transition. It is not the transition itself. Collapsing Decision and Promotion into an approved flag destroys the difference between permission to change reality and evidence that the change actually occurred.

Not a mutable current pointer

A pointer can identify a target, but by itself it cannot explain who authorized the change, which proposal and change set were integrated, when the transition occurred, or what evidence was considered. OntoGraph checks active Version state against the Promotion-derived result; it does not allow the pointer to become self-justifying truth.

Candidate state is computed independently

A proposal describes a possible future relative to an accepted base. The human shorthand is:

Candidate(proposal) = baseVersion + semanticChangeSet + governanceEvidence

The plus signs mean composition, not arithmetic and not automatic graph mutation. In the canonical model:

• baseVersionRef identifies the accepted context from which the proposal was authored;
• changeSetRefs identify the proposed semantic mutations;
• evidence, validation results, reviewers, Reviews, Decisions, gaps, and blockers preserve the proposal's governance lineage; and
• a stage-aware query derives what the existing records make the proposal ready to do next.

The candidate is not a second canonical truth. It is an addressable, inspectable possibility. Its readiness may change as evidence and governance records accumulate while the accepted package state remains stable.

Three realities can coexist

The reference example contains three states at the same time:

Reality	Derivation	Meaning
Accepted	Latest Promotion targets Version 1 and active state agrees	Version 1 is current.
Review-ready	Proposal A has a ChangeSet, assigned reviewer, and non-failing validation evidence	A human review may legitimately begin.
Promotion-ready	Proposal B also has an approving Review and Decision, but no Promotion	The change is authorized to advance but is not current.

The stage-aware rules are deliberately monotonic about evidence but not careless about state. Adding a Review can make a proposal decision-ready. Adding an approving Decision can make it promotion-ready. Neither operation rewrites the accepted Version. Only a distinct Promotion event establishes the governed transition into canonical visibility.

The plain-language review-without-making-it-live use case explains this scenario, while the executed proof case checks the three human answers against exact runtime values.

Four dimensions stay separate

OntoGraph preserves four questions that ordinary status-driven systems tend to collapse:

Dimension	Question	Representative records
Canonical state	What is included in the accepted package Version now?	Package, Version, Promotion
Epistemic state	What is asserted, and what supports or challenges it?	Assertion, Evidence, Source, ValidationResult, gaps
Governance authority	What has an authorized actor reviewed, decided, or permitted?	Actor, Review, Decision, authority evidence
Temporal and causal history	Which event actually changed visibility, and from what to what?	ChangeSet, Promotion, Version lineage, provenance

“Canonical state” is used here instead of “extensional” because extensionality already has a narrower technical meaning in ontology and OntoUML modelling.

Keeping the dimensions orthogonal prevents these category errors:

• stored information becoming accepted merely because it exists;
• validation becoming approval;
• approval becoming promotion;
• a higher version becoming current without a governing event; and
• imported or generated material silently becoming canonical truth.

Readiness is a derived answer, not a stored status

The stage-aware governance query derives one of several outcomes from the records actually present:

Proposal + ChangeSet + validation + reviewer       -> review-ready
+ approving Review                                 -> decision-ready
+ approving Decision                               -> promotion-ready
+ authorized Promotion                             -> promoted

Blocking authority, provenance, semantic, or validation gaps take precedence over these readiness outcomes. The result is not written back as one universal status; Proposal lifecycle, Review outcome, Decision outcome, Promotion, and Version state remain independently inspectable.

See the executed governance-stage-readiness query for the complete current outcome set.

Why this is a governance calculus

The system has the four ingredients needed for a bounded calculus:

1. Typed terms: Package, Version, Proposal, ChangeSet, Review, Decision, Promotion, Assertion, Evidence, and gaps are different kinds of thing.
2. Invariants: evidence requires provenance, Decisions are not changes, Promotions are not Decisions, and lifecycle dimensions cannot collapse into one status field.
3. Derivations: current state and readiness are computed from referenced canonical records under deterministic rules.
4. Witnesses: query output retains the IDs, lineage, caveats, and proof booleans needed to inspect how the answer was obtained.

This is stronger than retrieving a stored label and narrower than claiming a general theorem prover. The value lies in making governance distinctions computable without letting computation impersonate authority.

What this proves

For the bounded OntoGraph Core 0.4.0 memory/file Developer Preview, the published reference suite proves that the runtime can:

• return accepted state beside selected proposal states;
• derive current state from the latest Promotion record;
• reject an active-Version mismatch rather than laundering it as current;
• derive review-ready and promotion-ready outcomes without flattening them;
• preserve Proposal, Review, Decision, Promotion, and Version identities; and
• produce the exact expected read model for the published fixture.

The query contract explains how the fixture, runtime execution, exact comparison, and generated page fit together.

What this does not prove

The equations do not create canonical objects or define an alternative runtime. The query does not decide that a source is true, grant an actor authority, approve a Review, issue a Decision, execute a Promotion, certify a model, or authorize a release.

The current proof also does not establish concurrency semantics, a hosted multi-user governance service, a general query language, or equivalent behavior for Neo4j, Dgraph, SQL, RDF, or another production backend. Those remain outside the published memory/file boundary; see the published limitations.

The deepest rule is therefore simple:

Evidence can justify a decision. A decision can authorize a transition. Only the recorded Promotion establishes that the transition occurred.