Skip to main content
Status·Live-testing the fleet·Sales open Q3 2026
algovigilance
/anatomy
§anatomy

Anatomy of a
defensible decision.

Every decision in the fleet has the same five-layer structure. Identity, signature, governance, awareness, body. Same shape, same invariants, every time.

/order
§order

Why this order.

The five layers aren't a taxonomy. They're a sequence. Each layer establishes what the next layer is allowed to assume, and a decision that fails any layer never reaches the one below.

  1. /01

    Identity comes first because every reference downstream depends on knowing who the artifact is. Nothing can cite, audit, or revoke what it can't name.

  2. /02

    Type Signature comes second because it bounds what flows in and out. If the contract doesn't hold, no later gate can recover.

  3. /03

    Governance comes third because it determines who can see what runs and how the artifact is classified for risk.

  4. /04

    Awareness comes fourth because it stacks the claims a caller must trust — what the decision provides, what it promises, how it composes.

  5. /05

    Body comes last because it is the only layer that actually decides. The four above are pre-decision gates; the body is the verdict.

Wireframe model of a microgram

  1. /01.Identity
    Surface

    Names the decision and anchors it in the catalog.

    AIFDA Step 1 · Question of Interest
    invariant
    • addressable
  2. /02.Type signature
    Contract

    What goes in, what comes out, what may run.

    AIFDA Step 4a.i · Model description
    invariant
    • typed effects
  3. /03.Governance
    Policy

    Classification and observability posture.

    AIFDA Step 3 · Risk + Step 7 · Adequacy
    invariant
    • observation is metadata
  4. /04.Awareness
    Semantics

    What the decision claims, what callers must promise, what guarantees it offers.

    AIFDA Step 2 · Context of Use
    invariant
    • certification authority
  5. /05.Body
    Kernel

    The decision itself. Pure. Total. Signable.

    AIFDA Step 4b · Evaluation + Step 5 · Execute
    invariant
    • immutability
    • determinism
    • totality
  1. Layer 1Identity. Names the decision and anchors it in the catalog. Invariants: addressable.
  2. Layer 2Type signature. What goes in, what comes out, what may run. Invariants: typed effects.
  3. Layer 3Governance. Classification and observability posture. Invariants: observation is metadata.
  4. Layer 4Awareness. What the decision claims, what callers must promise, what guarantees it offers. Invariants: certification authority.
  5. Layer 5Body. The decision itself. Pure. Total. Signable. Invariants: immutability, determinism, totality.
/invariants
§invariants

The seven invariants.

Each layer carries one or more invariants the decision must hold. They are the contract between the artifact and everyone who relies on it — auditors, integrators, regulators, customers.

  • addressable
    Identity

    Every artifact has a unique, stable name. Anything downstream — references, audit trails, recall — depends on this.

  • typed effects
    Type Signature

    Every side-effect a decision may produce is declared up front. There are no hidden effects at runtime; nothing fires that wasn't already promised.

  • observation is metadata
    Governance

    Whether the decision is observed has no effect on what it does or what it is. Observation is a property of the surrounding system, never of the decision itself.

  • certification authority
    Awareness

    Every claim the decision makes must be backed by a published test that an outside party can verify. No self-certification, no hand-waving.

  • immutability
    Body

    Once signed, the decision is frozen. Any change produces a new artifact with a new name. The old one stays exactly as it was the day it was signed.

  • determinism
    Body

    The same inputs always produce the same outputs. No clocks, no randomness, no hidden state — what you ran yesterday will run the same way tomorrow.

  • totality
    Body

    Every input is answered. The decision is not allowed to loop forever, time out, or fall through. If it can't decide, it says so — clearly, and bounded in time.

/seal
§seal

The seal.

Every signed decision carries three things on its envelope. None of them are the decision itself — they're what lets anyone verify the decision later. The five layers above live inside the envelope; these three live on it.

  • hash
    what it is

    A content fingerprint. Any change to the artifact — any character, any byte — produces a different one. Two decisions with the same hash are the same decision, by construction.

  • signature
    who signed it

    Cryptographic proof that a specific signer authorized this exact artifact. The signature is mathematically tied to the hash above — change the artifact, the signature breaks. Change the signer, the signature breaks. Both are checked at load time.

  • timestamp
    when it was signed

    The instant the artifact was sealed, recorded in coordinated universal time. Sets the clock for expiry, freshness checks, and the audit trail.

Any of the three failing at load time — a hash that doesn't match, a signature that doesn't verify, a timestamp that's expired — is a refusal. Refusal is the design, not the failure mode.

/access
§access

Everything on this page is mechanically enforced by code. One artifact is public; the rest are available to auditors, integrators, and prospective customers on request.

  • The schema

    The formal definition of what an artifact looks like on disk. Published so any external validator can check that a file claiming to be a microgram actually is one.

  • The anatomy contractaccess on request

    The machine-readable record of the five layers, their invariants, and the regulatory mapping you see on this page. Single source of truth for everything above.

  • The decision calculusaccess on request

    The small, total functional language every decision body is written in. Designed so that writing valid syntax already establishes the properties auditors care about.

  • The decision recordaccess on request

    The complete set of architectural decisions that explain why the system looks the way it does — why these five layers, why this sequence, why these invariants and not others.

  • The drift guardaccess on request

    An automated check that refuses to pass if this page and the underlying contract ever fall out of sync. Keeps the public story and the private spec one document, not two.

To request access, contact algovigilance@gmail.com.