QIS-RG-001 QISTRUST.COM THE GOVERNANCE LAYER REV 2026-08-24 · BUILD 37

The Governance Layer · Reference implementation · RG-01

The reference gate.

The Schedule Set defines a common record for every governed quantity in the clause library: a limit, a value, a unit, an enforcement point, a consequence, and who set it and when. It closes by naming its own open question — a schema defines what a valid record looks like, not whether the thing it describes actually works. This is the answer. qis-gate is a small, deliberately unglamorous piece of software that takes a schedule conforming to that record and a proposed action, and returns a decision: permit it, reject it, or something in between that neither word quite covers. It is the first artifact in this ecosystem that runs rather than reads.

See it running, end to end

The worked example on this page is one command among five. The walkthrough runs the same schedule through all five stages — Define, Validate, Evaluate, Record, Inspect — with the real terminal output at each, in four minutes, from a clean install.

The case it exists to demonstrate.

A schedule is allowed to record a limit with no enforcement point. Row S-01-B-009 of the worked example schedule in the MARQUE working paper does exactly this — a permitted-instrument count, checked only in a nightly reconciliation report, its enforcement point recorded as “None. … it is not enforced pre-trade,” rather than left blank, so that the gap is visible on the schedule instead of absent from it. When a proposed action breaches a limit like that, two answers are available and both are wrong. Permit it silently, and the gap the schedule's author went out of their way to record disappears into a routine approval. Reject it, and the gate blocks something nothing in the actual system would have blocked — which is not a governance decision, it is a fiction. The gate returns a third answer, PERMIT_ADVISORY: the action proceeds, exactly as it would with no gate in front of it at all, and the record says plainly that a documented limit was exceeded and nothing stopped it. That one outcome, more than the other seven in the decision table, is the reason this package exists.

$ qis-gate evaluate --schedule s01b.json --action unenforced_breach.json
DECISION: PERMIT (ADVISORY)

  [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.
      Documented limit exceeded (observed 1 > limit 0 instruments). No
      enforcement point recorded; the gate cannot block this and did not.

What it does.

Three commands. qis-gate evaluate reads a schedule and a proposed action, checks the action against every row the schedule governs, and writes a decision and a per-row finding for each. qis-gate verify checks a ledger of past evaluations for tampering. qis-gate explain renders one past evaluation back into the same human-readable form evaluate prints, from nothing but the ledger. Every decision resolves to one of eight outcomes, run against the actual conformance corpus:

ConditionOutcome
Value within the row's limitPERMIT
Limit exceeded; an enforcement point is recordedREJECT
Limit exceeded; no enforcement point is recordedPERMIT_ADVISORY
Row's review date has passed as of the actionREJECT_STALE
Action references a quantity the schedule doesn't governREJECT_UNGOVERNED
Enumerated-set row; proposed value outside the setREJECT
Row is incompleteREJECT
Schedule fails schema validationFAIL_CLOSED

The boundary of what it does.

qis-gate reads two documents and returns a decision about the one action it was asked about — nothing wider. It does not place an order, does not set or adjust a schedule's values, and has no persistent connection to any order management, position keeping, or market data system. A PERMIT is not sign-off and a REJECT is not a finding of wrongdoing; each is the schedule's own answer to the question it was asked, recorded exactly, and no wider claim should be read into either one.

Determinism, and why it is enforced rather than assumed.

The same schedule and the same action, evaluated on different days, produce the same decision and the same findings. Staleness is checked against the action's own proposedAt timestamp, never against the clock the gate happens to run on — the one line of code that makes an evidence record from a year ago replayable evidence today rather than a claim nobody can re-check. Every evaluation is a pure function of its two input documents; only a record's own metadata — its id, its timestamp, its position in a ledger — varies between runs.

The schema it validates against, and where it came from.

The governed-quantity JSON Schema published on the capital pillar's open data surface is the same schema the gate ships inside itself — written into the package from the exact build step that publishes it here, so the two cannot silently drift apart. qis-gate evaluate makes no network call by default; --live-schema fetches the version published right now instead of the one the package shipped with, which is the only network call this package ever makes, and only on that explicit request.

The test corpus.

Built primarily around the real worked example from the MARQUE working paper rather than synthetic fixtures — the S-01-B schedule quoted above is the actual schedule from the paper, not a stand-in. One fixture exists for every row of the decision table, plus the boundary and fault-injection cases a decision table alone does not surface: an action proposed exactly on a row's review date (current, not stale), a ledger deliberately edited after an evaluation was appended (caught, and the exact record named), a ledger with a record removed (caught the same way). The corpus runs as part of this ecosystem's own build gate — a broken gate fails the site's build, not only its own test suite.

Relationship to the framework.

RG-01 completes the Schedule Set the way the Schedule Set itself completes the four instruments before it: by supplying, concretely, what the prior artifact left as form. It implements MARQUE Question 1, Authority and Question 3, Drift — a gate that evaluates a proposed action against a recorded limit is authority and drift stated as running code rather than as a question a reviewer asks. On KYA, it verifies D01, Authority, D03, Drift, and D04, Auditability: an institution that can run this gate against its own schedule, rather than describe its governance in narrative, is evidenced on whether it can demonstrate conformance, not merely claim it.

Source.

The package and its full test corpus are published on their own, separately from the rest of this ecosystem's source, at github.com/OceanGenius/qis-gate, under the MIT license. pip install git+https://github.com/OceanGenius/qis-gate, then qis-gate demo reproduces the worked example above with nothing else to configure. Requires Python 3.10 or later and one runtime dependency, jsonschema.