Ramin.

№ 03 · CHAPTER THREE · THE PATH

From feature to substrate. Governed all the way.

A tool advantage can be neutralised by a competitor buying the same tool. A substrate advantage compounds with every loop cycle run.

Governance is not a feature. It is the substrate. Every action carries its policy gate, its evidence trail, and its escalation path before it ever runs.

CANON · ARCHITECTURE CONTRACT

Safety is not an overlay.

  • Source sovereignty. Each data class is explicitly copied, normalised, referenced, federated, retained, exported, or deleted under policy.
  • Tiered autonomy. High-consequence decisions require human review by policy. The four operational states are bounded, not assumed.
  • Transparency by architecture. Every action logs its full reasoning chain. What was perceived, inferred, decided, and on what evidence.
  • The Red Button. The canonical requirement is a global execution pause within one processing cycle. A millisecond SLO requires production evidence.
  • Compliance as code. Your values and the regulations you operate under are versionable, testable, and enforced before any action is taken.
  • Auditable end-to-end. The target runtime records every material transition with actor, input, policy, model, time, hash, and outcome lineage.

TARGET · CUSTOMER-SPECIFIC PROGRESSION

Progression by evidence. Never by calendar alone.

Every tenant begins in Observe. Movement to Advise, Co-Execute, or Absorb is a target progression governed by measured outcomes and can regress when quality or calibration deteriorates.

  1. Trust Contract. Action classes, policies, evidence measures, owners, downgrade rules, and the Red Button are agreed.
  2. Observation. Read-only sources build STATE and confidence. No recommendations or execution.
  3. Advising. Recommendations are surfaced with evidence. Humans remain sole executors.
  4. Co-Execution. Drafts or staged actions require explicit approval at execution time.
  5. Absorption. Only bounded action classes with sustained evidence may execute within policy.

DEMO · FIRST-SCENARIO SPECIMEN

Start where two systems disagree about one customer.

The bounded first scenario joins Sales and Finance around one question: should a €240k expansion progress while €186.4k remains overdue under a different customer name?

1
TENANT
2
SOURCE CLASSES
1
CANONICAL CUSTOMER
1
GOVERNED DECISION

The website version uses fictional records. A customer Observe engagement replaces them with approved read-only source data and measured identity coverage.

Run the Sales + Finance scenario

TARGET · FIRST-SCENARIO BUYING MODEL

Install one scenario. Prove one loop.

The first purchase is a bounded Observe scenario, not the complete platform. It creates the evidence required to decide whether progression is justified.

  1. Scope. Name one tenant, domain, question, source set, decision class, and accountable owner.
  2. Connect. Provision one or two read-only sources and approve data-class handling.
  3. Resolve. Build the Identity Graph slice and measure entity coverage with a declared denominator.
  4. Observe. Surface one evidence-bearing belief or anomaly without creating a write path.
  5. Review. Verify findings, data lineage, policy scope, and commercial value with the customer team.
  6. Decide. Stop, extend Observe, or approve the next trust state based on measured evidence.