Core Concepts

Governance OS is built on eight primitives. Everything else — dashboards, reports, integrations — is metadata on top of these first-class objects.

The Eight Primitives

Policy

What is allowed, forbidden, or must be escalated. Explicit rules with temporal versioning.

Signal

Observed changes in reality. Timestamped facts with provenance (source, reliability).

Evaluation

Deterministic binding between signals and policies. Same inputs always produce same outputs.

Exception

Request for human judgment. Raised when policy is violated or uncertainty requires a decision.

Decision

Accountable human choice. Immutable record with chosen option, rationale, and assumptions.

Action

Constrained execution. What the system does within policy bounds or after a decision.

Outcome

What actually happened. Captured for learning and policy tuning over time.

Memory

Institutional learning. The accumulated evidence of how decisions were made and what resulted.

Policy

A Policy defines what is allowed, forbidden, or must be escalated for human judgment. Policies are:

  • Versioned — Every change creates a new version with temporal validity
  • Explicit — No implicit rules or hidden defaults
  • Testable — Given the same inputs, a policy produces the same evaluation result

Example policies:

  • Position in any single asset must not exceed 10% of portfolio value
  • Counterparty exposure above $5M requires CFO approval
  • Client portfolios must stay within 5% of target risk allocation

Signal

A Signal is an observed change in reality. Signals are timestamped facts that flow into the system continuously, not on a calendar. Each signal includes:

  • Type — What kind of signal (position update, price change, client request)
  • Payload — The structured data representing the observation
  • Source — Where the signal came from (Bloomberg, internal system, manual entry)
  • Reliability — Confidence level (verified, provisional, estimated)
  • Timestamp — When the observation was made

Evaluation

An Evaluation is the deterministic result of applying a policy to signals. Given the same policy version and the same signals, an evaluation always produces the same result:

  • Pass — All signals comply with policy
  • Fail — One or more signals violate policy
  • Inconclusive — Missing data or low confidence prevents determination

Evaluations are hashed and stored. The system can be replayed against historical data to verify determinism or test policy changes.

Exception

An Exception is a request for human judgment. Exceptions are raised when:

  • A policy evaluation fails (violation detected)
  • Uncertainty prevents automatic resolution
  • The situation falls outside defined policy bounds

Each exception includes:

  • Severity — Critical, High, Medium, Low
  • Context — All relevant signals and policy details
  • Options — Symmetric choices presented without recommendation

Exceptions are not bugs or errors. They are the system working as designed — surfacing moments where human judgment is required rather than automating past the point of accountability.

Decision

A Decision is an accountable human choice made in response to an exception. Decisions are immutable records that capture:

  • Chosen option — Which path was selected
  • Rationale — Why this choice was made
  • Assumptions — What beliefs informed the decision
  • Decided by — Who made the call
  • Timestamp — When the commitment was made

Once recorded, a decision cannot be changed. If circumstances change, a new exception is raised and a new decision is made.

Evidence Pack

An Evidence Pack is a deterministic bundle that answers: "Why did we do this?" Generated automatically after each decision, it includes:

  • The decision record (option, rationale, timestamp, user)
  • The exception that triggered it
  • The evaluation result and policy version
  • All contributing signals with provenance
  • SHA-256 content hash for integrity verification

Evidence packs are designed for audit, regulatory examination, and board-level review. They can be exported as JSON, HTML, or PDF.

Domain Packs

Domain-specific vocabularies are configured through Packs. A pack provides:

  • Signal types specific to the domain
  • Policy templates with domain vocabulary
  • Option templates for common decisions
  • UI copy and terminology

Currently supported packs:

  • Treasury — Position limits, volatility, credit risk, cash forecasting
  • Wealth — Suitability, drift, concentration, tax optimization

Same loop, same primitives, different vocabularies. Treasury and Wealth are configurations, not forks. The governance kernel is identical.

Learn how these concepts flow together →