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.
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:
| Condition | Outcome |
|---|---|
| Value within the row's limit | PERMIT |
| Limit exceeded; an enforcement point is recorded | REJECT |
| Limit exceeded; no enforcement point is recorded | PERMIT_ADVISORY |
| Row's review date has passed as of the action | REJECT_STALE |
| Action references a quantity the schedule doesn't govern | REJECT_UNGOVERNED |
| Enumerated-set row; proposed value outside the set | REJECT |
| Row is incomplete | REJECT |
| Schedule fails schema validation | FAIL_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.