Decisions have never been a first‑class object in enterprise software.

Locate — Resolve where you are before you decide

Every decision happens in a context — a department, a jurisdiction, a customer tier, a regulatory regime. That context determines everything downstream: which rules apply, what terms mean, who has authority, what precedent is eligible. Most systems treat context as metadata, attached after the fact. Ordinant treats it as the decision's coordinates — resolve them first, or nothing that follows can be trusted.

This is why the same question gets different answers across the organization without anyone realizing they were operating under different rules. "Active customer" means one thing in Sales, another in Finance, another in Legal — and all three are correct, within their scope. The problem isn't disagreement. It's that no system pins which definition was in force when the decision was evaluated.

Scope as coordinates — Scope isn't metadata about a decision — it's part of the decision's identity. Change the scope and you have a different decision, because different rules, authorities, and constraints apply.

Rules pinned as-of — Policies and meanings are bound to the moment of decision. When the rules change tomorrow, today's decision remains valid against today's rules — auditable, replayable, unambiguous.

Local meaning — "Revenue" means what it means in this context, under these rules, at this time. No prerequisite for enterprise-wide semantic agreement. When contexts cross, the transformation is explicit.

Fail closed on ambiguity — If a required scope dimension can't be resolved, or the applicable rules are unclear, the system stops and routes for review. No proceeding under the wrong regime.

Evaluate — Test against the procedure, not the person

With scope resolved and rules pinned, the system establishes what evidence is admissible, what claims must be made and sourced, how conflicts resolve, who has authority, and what has to be true for the decision to close. Exploration can be messy, probabilistic, AI-assisted — but the moment of closure is strict. The procedure contract either passes or it doesn't.

Decision as procedure — Each decision has a specification: required evidence, required claims, closure criteria, tolerances, escalation rules, authority and separation of duties. A contract, not a conversation.

Typed evidence & claims — What counts as evidence is declared up front. Claims must be sourced and typed. No undocumented assertions. No "it depends" without knowing what it depends on.

Deterministic closure — A decision closes when explicit criteria are met — not when someone signs off. AI can propose. Humans can deliberate. But the gate is structural.

Conflicts surface, not hide — Conflicting evidence, insufficient authority, or out-of-tolerance claims are represented as structured data — not buried in a chat thread or email chain.

Seal — Capture the why at the moment it's true

When a decision closes, the system seals a decision record at that moment — capturing what was decided, the scope and rules it was evaluated against, the evidence that was considered, the claims that were made, who had authority, and what closure criteria were satisfied. This record isn't documentation. It's the structural artifact that makes everything downstream possible: reuse depends on it, execution derives from it, and audit is simply reading it.

Sealed at closure — The record is produced as a consequence of closure — not as a separate documentation step. If the decision closed, the record exists. No gap.

Why, not just what — The record commits to the rules in force, the evidence admissible, the authority that validated it, and the scope it applies to. A verifiable chain, not a narrative.

Reuse-ready by construction — Because the record carries its scope, reference frame, and validity conditions, it's immediately available as precedent — without anyone tagging or curating it.

Audit becomes retrieval — "Why did we decide that?" is a lookup, not an archaeological dig. The record was created at the moment of decision, not assembled from memory afterward.

Match — Find precedent by applicability, not similarity

When a new decision request arrives, the system's first move isn't to start reasoning. It's to check whether a proven precedent already covers this case. Matching is structural: does the scope of an existing decision record contain the new request's scope? Is the reference frame still valid — same rules in force, same definitions, same authority regime? If both conditions hold, the precedent applies. If either fails, the system knows exactly why and routes to new evaluation.

This is fundamentally different from similarity search. Vector similarity tells you "these situations look alike." Structural applicability tells you "the conditions that made this answer valid still hold." One is a suggestion. The other is a guarantee.

Scope containment — A decision at a broader scope covers requests at narrower scopes beneath it. One decision can eliminate re-evaluation for every combination underneath — automatically.

Frame compatibility — The rules, definitions, and authority regime must still be in force. If anything changed, the system identifies exactly what shifted and whether it's material.

Bind — Reuse proven judgment or compile new precedent

When a match is found, the system binds to existing precedent — the answer is already there, already validated, already carrying its conditions. No re-litigation. No committee. No scavenger hunt through Slack.

When no precedent matches — genuinely novel situation, changed rules, new scope — the system routes to fresh evaluation through the Decide pipeline. And when that new evaluation closes, its result compiles into new precedent. Every novel decision makes the system smarter. Judgment compounds.

Reuse before inference — The system's default is to bind to proven precedent. New reasoning is the fallback for genuinely novel situations — the expensive path, not the default one.

Novelty compiles to reuse — New evaluations aren't throwaway. Every closed decision becomes precedent for future cases. The thousandth decision is faster and better than the first.

Retire — Invalidate precedent when the world changes

Precedent doesn't live forever. When rules change — a policy update, a regulatory amendment, a delegation restructure — the system identifies every decision record affected by the change, selectively and by scope. Precedent that was valid under the old rules is retired for future use. Precedent unaffected by the change continues to apply. No blanket invalidation. No zombie decisions silently applying rules that no longer exist.

Selective by scope — A rule change in the APAC finance department doesn't invalidate precedent in EMEA operations. Retirement is precisely scoped to what actually changed.

No zombie decisions — Expired precedent is marked, not deleted. The historical record remains — but it can't silently bind to new cases under rules that no longer apply.

Mint — Derive the right to act from the decision itself

A closed decision doesn't just produce a record. It mints an execution warrant — a specific, time-limited, scope-bound right to perform one action with defined parameters. The warrant carries the decision reference, the authorized parameters, the governing conditions, and a temporal limit. What it doesn't carry is identity. No credentials, no role memberships, no session tokens. Authorization derives from what was decided, not from who's asking.

Decision-derived authorization — The right to act flows from the decision, not from identity. What you're allowed to do is determined by what was decided — not by who you are or what role you hold.

Parameter-bound — The warrant authorizes this specific action with these specific parameters. Any modification — amount, target, scope — invalidates it. No drift from what was authorized.

Time-limited, single-use — Warrants expire. They can't be reused, replayed, or stockpiled. The right to act is precisely as broad and as long-lived as the decision justifies — and not a millisecond longer.

Identity excluded — No identity-derived factor participates in the authorization scope. Credential theft is structurally irrelevant when credentials aren't in the authorization path.

Verify — Structural separation between reasoning and action

The execution boundary is architecturally separated from the reasoning domain. No direct path exists from analysis components to side-effect-producing endpoints — regardless of component identity or credentials. The warrant is the sole bridge. At the boundary, ordered verification confirms integrity, condition satisfaction, parameter binding, and validity status before any effect is produced.

This means a compromised reasoning component — an agent that's been manipulated, a service with stolen credentials — cannot directly produce side effects. It can only present a warrant to the boundary. And the boundary checks the warrant, not the presenter.

Structural domain separation — Analysis and effect are architecturally separate. No reasoning component can reach an execution endpoint directly. The warrant is the only bridge — by design, not by policy.

Bounded blast radius — A compromised component can only exercise rights that specific decisions have already authorized for specific parameters. No lateral movement. No inherited permission scope.

Receipt — Prove what was authorized and what occurred

Execution produces a receipt — generated at the trust boundary at the point of effect, not reconstructed afterward. The receipt binds the performed action back to the originating decision: what was authorized, what parameters were used, what boundary verified it, and when. Committed status is computed from the receipt at query time — a derived fact, not a mutable flag in a database that can be corrupted, fabricated, or silently diverge from reality.

Proof at point of effect — The receipt is generated by the trust boundary component that actually invoked the operation — not by the component that requested it. No self-reported execution.

Derived committed status — "Did this actually happen?" is computed from the receipt, not read from a stored flag. Status can't drift from reality because it's derived from reality.

Revoke — Invalidate outstanding authority in real time

When policy changes, when a delegation is withdrawn, when a decision is overturned — any outstanding warrants derived from that decision are invalidated immediately. Not at the next sync cycle. Not when someone notices. At the moment the change is published, every warrant that depended on the prior state becomes unexercisable. The execution boundary checks validity status on every verification. There is no window between policy change and enforcement.

This is the property that identity-based authorization fundamentally cannot provide. In a role-based system, revoking a permission requires updating every session, token, and cached grant — a propagation problem that's never fully solved. In Ordinant, the warrant checks against a revocation register at the boundary. The moment the register updates, the warrant is dead. Zero propagation delay.

Instantaneous invalidation — Outstanding warrants are checked against a revocation register at the point of execution. Policy change → register update → warrant rejected. No propagation window.

No stale authority — An employee changes roles at 2:00 PM. At 2:01 PM, every warrant derived from their prior authority is unexercisable — not because a sync ran, but because the warrant checks live state at the boundary.