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 case it exists to demonstrate.

Every governance row declares an enforcementStatus: enforced, unenforced, or partial — a control exists that detects a breach but does not prevent it. Row S-01-B-009 of the worked example schedule in the MARQUE working paper is partial: a permitted-instrument count, checked only in a nightly reconciliation report, with no pre-trade control at all. 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 others 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 (partial): 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).
      Declared partial: detection exists but does not prevent the action;
      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; enforcementStatus is enforced	REJECT
Limit exceeded; enforcementStatus is unenforced or partial	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.

Asking before acting, not after.

A command line answers a person, and a CI step answers a build. Both arrive after the fact, or beside it. The gate also serves the Model Context Protocol, so the agent itself can ask — at the moment it is deciding, which is the only moment a governed limit can still change what happens:

pip install git+https://github.com/OceanGenius/qis-gate
qis-gate mcp

Register that as a stdio MCP server and an agent gets three tools: evaluate_action (may I do this, given this schedule — returning the same sealed record the command line produces), verify_ledger, and explain_decision. The action is passed inline, because an agent holds an action, not a file; the record hashes the content either way.

It runs on the caller's own machine and makes no network calls. That is the point rather than a limitation: a schedule is an institution's record of what authority it granted and to whom, and a ledger is its evidence. A hosted evaluator would mean a firm posting its own authority limits to someone else's server to find out whether its own agent may act. A rejection is also not an error. Every decision the gate reaches — including REJECT — returns as a successful tool result, because an agent framework that retries on tool errors would otherwise read “you are not authorized to do this” as a transient fault and try again.

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.