A picture led walk
through the gate.

Plain English

Today, when something goes wrong, the regulator asks the firm to send over the logs. Those logs were written by the firm’s own systems. If someone edited them, deleted them, or never wrote them, the regulator has no way to tell.

The fine arrives after the breach, not before it. The cost of the breach (a vulnerable customer reached, a self excluded gambler messaged, a piece of credit advertising that broke the rules) is already paid by the time the audit completes.

This is the position the UK Gambling Commission’s October 2025 framework, the FCA Consumer Duty regime, and Article 12 of the EU AI Act are pushing past. “Trust us” is no longer a defence.

Technical detail

The standard pattern is the application layer policy gateway: a filter in front of the agent or the marketing engine reads outbound traffic and reports back. The filter, the engine, the logs, the deployment, and the key material that signs any receipts are all controlled by the same operator. The audit trail is what that operator chose to write.

Three failure modes recur:

• Pre deployment training: instructing a language model to follow the rules is not deterministic, not auditable, and not evidence.
• Centralised logs: the tenant trusts the platform’s honesty and retention. No cryptographic per action proof; no independent rerun.
• Single authority gateways: the operator owns the policy, the engine, the logs, and the receipts. The regulator inherits all of that trust.

The gap the gate closes: a regulator or counsel asked to rely on any of the above is being asked to trust the operator’s word about the operator’s own behaviour.

Plain English

Nothing regulated leaves the building until the checkpoint has read it, checked it, and stamped it. If the message is fine, it goes through and gets a sealed receipt. If it is not, it stops at the gate with a written reason: which rule was broken, in plain language.

The regulator no longer chases edited logs after the breach. The gate’s stamp is the receipt: the firm can show it, the regulator can recompute it, an independent auditor can read it. No single party can wave a message through or quietly delete a refusal.

The same shape covers seven verticals on the Industries page: gambling, FCA debt collection, financial promotions, UK GDPR, Consumer Duty, community pharmacy, EYFS childcare. The mechanism does not change; the rulebooks do.

Technical detail

The gate sits at the last controllable moment before the action becomes real or irreversible. That is the egress: the SMTP relay accepting the message, the SMS aggregator submitting, the SIP INVITE sent to the carrier, the push API call, the publish webhook, the database commit, the unlock signal to an actuator.

Every action is normalised into one canonical shape: an ActionDescriptor carrying the action kind, the tenant, the operator, the target, the cryptographic fingerprint of the payload, jurisdiction, vertical, the contextual flags (recipient self exclusion status, vulnerability flag, affordability band, age band, hour of day, hours window), consent reference, lawful basis, ruleset identifier, validity window, and a nonce.

Two deployment shapes (see Integrations): Inline blocks on refuse (the surface returns HTTP 451 or the actuator stays in its safe default); Out of band mirrors the egress and writes a tamper evident violation record without ever blocking. Same verdict, same proof, same evidence shape.

Plain English

The gate reads two rulebooks at once. The regulator’s baseline is what the law says everyone must do. The firm’s overlay is the internal policy, written by the firm’s own General Counsel team, usually stricter than the baseline.

Both check the same message. If either says no, the message stops. Neither the regulator nor the firm can quietly relax a rule without the other side seeing.

An overlay that tried to be more permissive than the baseline is rejected at compile time. The compose tool refuses to publish a composition where the firm’s rules loosen the regulator’s rules. The composer is conservative: a deny in either component is a deny in the composition.

Technical detail

Both rulebooks are written in a deterministic authorisation policy language with a published static analyser. The composer is a deterministic merge whose source and version are themselves ledger resident. The static analyser proves at compile time that the composition’s permit set is a subset of the baseline’s permit set.

The composed ruleset’s identity is the triple (RegulatorBaselineVersionHash, TenantOverlayVersionHash, ComposeRuleVersionHash), hashed to ComposedRulesetHash. Every action’s certification binds to a specific ComposedRulesetHash; any third party with ledger read access can independently reconstruct which rules applied at any historical block height.

This solves the “silently loosened the rules” failure mode. There is no single authority over the operating ruleset. There is no operator only path to change it.

Plain English

A composed ruleset is not active until two role typed signers have co signed it. One is the regulator aligned signer (it says “the baseline portion is faithful to the regulator’s published material”). One is the tenant’s own signer (it says “the overlay portion is faithful to our counsel’s content and we accept the composition”).

The tenant’s signature must be from the tenant’s own key, held on the tenant’s own infrastructure. A signature from tenant Alpha’s key does not activate a ruleset for tenant Beta; the gate refuses with CROSS_TENANT_BINDING.

An optional RoleHumanSigner covers the high stakes cases where a regulator or the firm’s own policy requires a named person to sign off in person (a senior officer for vulnerable customer overrides, for example).

Technical detail

The quorum policy is M-of-N with the requirement that M includes at least one valid signature from RoleRegulatorBaseline AND at least one from RoleClient whose tenant identifier matches the descriptor. The platform operator’s signatures cannot, in any number, activate the bundle alone.

Signature scheme: an unforgeable digital signature standard. Hash: a standard cryptographic fingerprint. The signer interface is quorum.Signer. Today the per tenant signing key lives in software inside the platform operator side process for demonstration; the substitution to an out of process client hosted signer over a mutually authenticated channel is named openly in the white paper’s trust hardening section as “Client hosted signer (Layer 1)”.

Cross tenant binding is enforced at the consensus layer, not in middleware. Every honest validator runs the check independently. A Byzantine validator that tries to admit a cross tenant binding is constrained by the BFT honest supermajority assumption (see chapter five).

Plain English

The certification check is not a middleware filter that runs in one place. It is a rule of the distributed ledger’s consensus engine. Every validator node runs the check before voting.

If one validator is faulty (or actively malicious within the configured fault threshold), the honest majority still refuses the block. The action does not commit. The gate cannot be bypassed by attacking a single validator.

Today the reference embodiment runs four validators with a tolerance of one bad node (N=4, f=1). The mature target topology distributes the validator set across Kronaxis, the tenant, the auditor, and a neutral notary so that no single commercial party holds a majority.

Technical detail

The reference embodiment uses a production deterministic Byzantine fault tolerant consensus engine with a pre execution block proposal hook. The pre execution hook is ProcessProposal. The check is engine independent: any deterministic BFT consensus protocol with a pre execution hook at block proposal time suffices.

Before voting for a proposed block, every validator independently:

1. Recomputes the canonical hash H(d) of the descriptor.
2. Looks up the matching quorum attestation row addressed by H(d) and ComposedRulesetHash.
3. Verifies each role typed signature on that attestation against the certifier registry at this block height.
4. Verifies that the recorded ComposedRulesetHash matches the currently active composition for the tenant.
5. Verifies that the attestation’s validity window is open at this block height and that the freshness stamps for every consulted register are within the contracted SLA.
6. Refuses to pre vote for any proposed block containing an action that fails any of the above; the refusal carries a code from the published taxonomy.

Scenario T5 in the reference embodiment exercises a single Byzantine validator pre voting for an uncertified action; the honest three of four refuse; the block does not commit; the action counter stays at zero cluster wide.

Plain English

The sceptical question a regulator asks first: how do you verify a recipient is not self excluded without a real time lookup against the upstream register at the moment of every send?

The answer is named freshness. The permit carries a stamp per consulted register: a snapshot version, the timestamp the snapshot was applied locally, the timestamp the gate checked it, the age of that check, and the contracted Service Level Agreement window. If the age exceeds the SLA, the gate refuses.

Between pre certification and send, fresh sync events keep an in window invalidation set. A self exclusion registered ten seconds before send is honoured.

The check is local and fast. The freshness is named in the rule set, signed by the regulator. The operator cannot widen the freshness SLA without the regulator co signing.

Technical detail

The per action proof carries, for each consulted register r:

• RegisterID_r: which register (GAMSTOP, sanctions list, TPS, etc.).
• VersionHash_r: cryptographic identifier of the register snapshot.
• AppliedAtUnix_r: when the snapshot was applied to the local replica.
• CheckedAtUnix_r: when the gate read the local replica.
• AgeAtCheckSeconds_r: the age of the snapshot at the moment of the check.
• SLAWindowSeconds_r: the contracted maximum age, set by the co signed rule set.

The refusal code is REFDATA_STALE. The error direction under partial failure is over suppress: if the local replica falls behind, the gate refuses; there is no “send anyway because the feed is down” path. A sustained upstream outage halts the operator’s campaigns until the sync recovers.

This is the formal answer to the practical question. Freshness is not the absence of a real time lookup; it is a named, contracted, stamped, fail closed substitute for one.

Plain English

Three plain mechanisms turn the verdict into a receipt no one can fake:

• Fingerprint. Every byte of the descriptor goes into a standard cryptographic fingerprint. Change one character and the fingerprint changes completely. The receipt points at the fingerprint, not at the bytes; you cannot edit the bytes and keep the receipt valid.
• Seal. Several independent signers seal the receipt: the regulator’s key, the firm’s key, the auditor’s key. No single party can forge a complete seal.
• Rerun. The rule is a written text everyone has the same copy of. Run it again on the same descriptor on a fresh machine and you get the same answer. There is no random AI score, no “you had to be there”.

None of these is new science. All are standard cryptography you have used today without noticing (when you visited a website over HTTPS, when you downloaded an app from a store, when your bank signed a transaction).

Technical detail

The receipt’s leaf hash is folded with its sibling hashes (the audit path) one level at a time using the same domain separated cryptographic hash the gate used. The final value should equal the published log root.

This is a standard tamper evident inclusion proof (the same primitive Certificate Transparency uses). The fold runs in your browser via the standard Web Crypto API on the proof page. Flip a nibble on any input and the result diverges by roughly half its bits.

The policy decision engine is deterministic by construction. Its policies have bounded evaluation time and a static analyser. A regulator with the same rule text and the same descriptor reads the same verdict and the same refusal code on their own machine.

The deterministic descriptor canonicalisation rule is length prefixed binary encoding with sorted field order. Any independent implementation that follows the specification produces byte identical bytes from byte identical logical content.

The verifier kc-verify on the For regulators page rederives every claim in the bundle from scratch, against the bundle alone, without calling Kronaxis.

Plain English

Put together, the gate gives a regulator and a buyer’s General Counsel a position they could not otherwise have. No single party can wave a regulated message through. No single party can change the record. No single party can hide a refusal.

The receipt is independent of us. The seal you cannot forge, the receipt you cannot edit, and the rule you can rerun are the three pieces that turn “we promise” into “here is the maths.”

The pilot is a six week Observe only deployment on one outbound surface. No card at the start. No invoice on walk away. The buyer keeps every byte of the evidence.

Honest residual

What the gate does not claim:

• That the deposited regulator baseline is the legally correct interpretation of the regulator’s rules. The substance of the baseline is the regulator’s.
• That the deposited tenant overlay is legally adequate for the tenant’s particular risk position. The substance of the overlay is the tenant’s counsel’s.
• That no regulator action will ever later find the deposited ruleset incomplete. The deposited ruleset is the firm’s responsibility.
• That the Kronaxis side software is bug free. The cryptographic invariants stand; software defects in the policy authoring tools or audit console are managed by ordinary software quality processes.

Operational hardening that strengthens the picture beyond today’s structural foundation: hardware backed signing keys, hardware attested signers, a client hosted layer one signer, reproducible builds for the signer, multi party validator distribution, a public transparency log mirror, persistent ledger state on disk, a biometric mobile signer for HUMAN_SIGNOFF_REQUIRED. Each is named openly in the white paper, with the substitution point stated for each.