One schedule. Five stages. Nothing simulated.

Before you start.

Everything below — every command, every line of output, every hash — came from one continuous terminal session against a clean install of the published, public qis-gate package, run on 2026-08-24. It is not illustrative and nothing is hand-typed. Two values will differ if you run this yourself: the recordId and the two sha256 hashes, because they are computed at the moment of evaluation — the decision and every finding will not differ. One value in the schedule itself is a deliberate placeholder: [Name], standing in for the natural person who set each limit, exactly as the worked example ships in the MARQUE working paper and in qis-gate's own test corpus. Nothing else on this page is a placeholder.

$ pip install git+https://github.com/OceanGenius/qis-gate
$ git clone https://github.com/OceanGenius/qis-gate
$ cd qis-gate

The schedule.

A governed-quantity schedule is where an authority boundary stops being a sentence in a risk policy and becomes a record: a limit, a unit, an enforcement point, a consequence, and the named individual who set it and when. S-01-B below is the two-row fixed-income schedule published in the MARQUE working paper, reproduced here exactly as it ships in qis-gate's own fixture corpus — not retyped for this page. Row S-01-B-009 is the row the rest of this walkthrough follows: a permitted-instrument count of zero, its enforcement point recorded as the word “None,” because pre-trade enforcement for it does not exist yet. Build a record like this yourself, validated live, with the Schedule Builder.

$ cat tests/fixtures/schedules/s01b.json
{
  "scheduleId": "S-01-B",
  "version": "1.2",
  "effectiveDate": "2026-07-01",
  "attachesTo": { "instrumentId": "QIS-CL-001", "instrumentVersion": "1.0" },
  "kind": "governance",
  "rows": [
    {
      "identifier": "S-01-B-004",
      "quantity": "Aggregate notional committed by the system to any single counterparty, across all open orders and filled positions",
      "value": 25000000,
      "unit": "USD",
      "measurementWindow": "Rolling, evaluated on each order submission",
      "dataSource": "Position keeping system PKS-2, counterparty exposure view, refreshed on fill",
      "enforcementPoint": "Pre-trade risk gate ORG-3, order rejected before transmission",
      "consequence": "Order rejected; reserved-action escalation to the Accountable Individual under Article 4",
      "setBy": "[Name], Head of Market Risk",
      "dateSet": "2026-06-24",
      "basis": "Set at one half of the desk's existing human single-counterparty ceiling, pending twelve months of live performance data before any increase is considered.",
      "reviewDate": "2026-12-24",
      "supersedes": { "identifier": "S-01-B-004", "version": "1.1" }
    },
    {
      "identifier": "S-01-B-009",
      "quantity": "Count of distinct instruments the system may hold outside the enumerated permitted set at Schedule S-01-A",
      "value": 0,
      "unit": "instruments",
      "measurementWindow": "Continuous",
      "dataSource": "Order management system OMS-1, instrument master reconciliation",
      "enforcementPoint": "None. The permitted-instrument set is checked in a nightly reconciliation report; it is not enforced pre-trade.",
      "consequence": "No automated consequence. Exception appears in the following business day's reconciliation.",
      "setBy": "[Name], Head of Market Risk",
      "dateSet": "2026-06-24",
      "basis": "The value is the intended limit. It is recorded with no enforcement point because none exists today; pre-trade enforcement is scheduled for Q4 2026. Recorded rather than omitted so that the gap is visible on the schedule.",
      "reviewDate": "2026-10-01"
    }
  ]
}

[Name] is the one placeholder value on this page — stated here rather than left for you to wonder about.

Schema conformance.

A schedule is only evidence if it conforms to a schema someone else can check it against. The governed-quantity JSON Schema is normatively defined by the Schedule Set, published on the capital pillar's open data surface, and shipped inside qis-gate itself — generated from the same build step that publishes it, so the two copies cannot drift apart. Below, the exact schedule from Stage 1 is validated against the exact copy the package ships with, using nothing but the standard jsonschema library.

$ python3 -c "
import json, jsonschema
schema = json.load(open('src/qis_gate/data/governed-quantity.schema.json'))
schedule = json.load(open('tests/fixtures/schedules/s01b.json'))
jsonschema.Draft202012Validator(schema).validate(schedule)
print('VALID against', schema['\$id'], '(schema version', schema['version'] + ')')
"
VALID against https://qisfund.com/api/governed-quantity.schema.json (schema version 1.0.0)

Validation confirms conformance to the schema. It does not confirm that the limits are the right limits, that [Name] had authority to set them, or that the schedule is legally sufficient — only that the record is structurally complete and checkable, which is the precondition for everything that follows.

A proposed action, against the schedule.

This is the Reference Gate, qis-gate, doing the one thing it exists to do: given the schedule above and a proposed action — here, an order that pushes the permitted-instrument count to one, against a recorded limit of zero — it returns a decision. Two easy answers were available here and both are wrong: permit the breach silently, and the documented gap disappears into a routine approval; reject it, and the gate blocks something nothing in the real system would have blocked. qis-gate returns a third answer instead, and says exactly why.

$ qis-gate evaluate --schedule tests/fixtures/schedules/s01b.json \
                     --action tests/fixtures/actions/unenforced_breach.json \
                     --ledger ledger.jsonl
========================================================================
DECISION: PERMIT (ADVISORY)
========================================================================

Record    RG-2026-08-24-0bb608b57765
Evaluated 2026-08-24T13:24:50Z  (qis-gate 1.0.0)
Action    ACT-2026-08-20-0003  (order.submit)
System    OMS-1
Schedule  S-01-B v1.2 -> QIS-CL-001 v1.0

Findings (1)
------------------------------------------------------------------------
  [PERMIT (ADVISORY)] row S-01-B-009
      observed 1 vs. limit 0 instruments
      enforcement: None. The permitted-instrument set is checked in a nightly reconciliation report; it is not enforced pre-trade.
      set by [Name], Head of Market Risk on 2026-06-24
      Documented limit exceeded (observed 1 > limit 0 instruments). No enforcement point recorded; the gate cannot block this and did not.

------------------------------------------------------------------------
scheduleHash     sha256:7823c38259ca37089e97d8eff302942f56dafa4cfb084f0720038df33ec98ea5
recordHash       sha256:b156ac3a6438fac57882442d108e37110d4b94aaf2e885c9f8dc776fe0093c39
previousRecordHash  (first record in ledger)
========================================================================

On your own run, recordId, Evaluated, and both hashes will differ — they are computed at evaluation time. DECISION: PERMIT (ADVISORY) and every finding will not: the same schedule and action always produce the same decision, on any day, on any machine.

The ledger entry.

The --ledger flag above appended that decision to a local, append-only file as one line of JSON. Below is that exact record, pretty-printed. previousRecordHash is null because this is the first record in a new ledger; every record after the first carries the prior record's recordHash, which is what makes it a chain — change one byte of any past record and every hash computed from it forward stops matching, and qis-gate verify --ledger ledger.jsonl names the exact record where the chain first breaks rather than merely reporting that something is wrong.

$ python3 -m json.tool ledger.jsonl
{
    "action": {
        "actionId": "ACT-2026-08-20-0003",
        "actionType": "order.submit",
        "system": "OMS-1"
    },
    "anchor": null,
    "decision": "PERMIT_ADVISORY",
    "evaluatedAt": "2026-08-24T13:24:50Z",
    "findings": [
        {
            "dateSet": "2026-06-24",
            "enforcementPoint": "None. The permitted-instrument set is checked in a nightly reconciliation report; it is not enforced pre-trade.",
            "limit": 0,
            "observed": 1,
            "outcome": "PERMIT_ADVISORY",
            "reason": "Documented limit exceeded (observed 1 > limit 0 instruments). No enforcement point recorded; the gate cannot block this and did not.",
            "rowId": "S-01-B-009",
            "setBy": "[Name], Head of Market Risk",
            "unit": "instruments"
        }
    ],
    "gateVersion": "1.0.0",
    "previousRecordHash": null,
    "recordHash": "sha256:b156ac3a6438fac57882442d108e37110d4b94aaf2e885c9f8dc776fe0093c39",
    "recordId": "RG-2026-08-24-0bb608b57765",
    "schedule": {
        "attachesTo": {
            "instrumentId": "QIS-CL-001",
            "instrumentVersion": "1.0"
        },
        "scheduleHash": "sha256:7823c38259ca37089e97d8eff302942f56dafa4cfb084f0720038df33ec98ea5",
        "scheduleId": "S-01-B",
        "version": "1.2"
    }
}

The anchor field is deliberately null in this version — a place reserved for a future external timestamp, not implemented here. This is content hashing for tamper evidence, over a local append-only file with one writer, not a distributed or externally-anchored ledger; no wider claim should be read into it.

What this decision actually implicates.

A decision is only evidence of something if it is legible against the framework it came from. qis-gate inspect is the fifth command — the one this ecosystem was missing until Build 36 — and it closes exactly that gap: given a record id, it resolves the schedule's own attachesTo.instrumentId against a published lookup and names the MARQUE question and KYA dimension the decision above actually implicates. No one had to cross-reference the graph by hand to get this answer.

$ qis-gate inspect --record RG-2026-08-24-0bb608b57765 --ledger ledger.jsonl
Record     RG-2026-08-24-0bb608b57765
Decision   PERMIT_ADVISORY
Schedule   S-01-B v1.2 -> instrument QIS-CL-001  (The Agent Authority Grant)

Implements  QIS-MQ-01 -- Authority
Verifies    D01 -- Authority

Rows evaluated (1):
  S-01-B-009       PERMIT_ADVISORY

The lookup inspect reads from is published in the open, computed rather than hand-typed, at api/instrument-index.json.

What five stages, run once, demonstrate.

Taken together, these five stages show that an authority boundary a human wrote down becomes a machine-evaluable record; that record produces a deterministic decision instead of a judgment call made under pressure; the decision leaves tamper-evident evidence behind it; and that evidence resolves back, on its own, to the exact governance question it was testing — without a person cross-referencing the graph, the schema, or the framework by hand at any point in the chain.

The five components, on their own pages.

This page is an editorial demonstration published by the QIS Ecosystem, built from the public, open-source qis-gate package under the MIT license. It is not legal advice, not a compliance determination, and not a certification that any institution's own schedule is correct.