DEV Community

logik systems
logik systems

Posted on • Originally published at logik-systems.com

Designing a Pre-Execution Governance Gate for AI Calls

#ai #architecture #cryptography #distributedsystems

Designing a Pre-Execution Governance Gate for AI Calls

Most AI-governance systems observe a decision after it has already happened.
That is useful for reporting, but it is too late to prevent a disallowed request
from reaching a model provider.

We are testing a stricter boundary: a deterministic governance decision must
complete before an external AI request is released.

This post describes the architecture, the evidence model already implemented in
Logik Systems, and the benchmark that still has to be passed. It is an
engineering design, not a compliance or performance claim.

The operational problem

The EU AI Act separates record-keeping and human-oversight requirements. Article
12 addresses automatic logging capabilities for high-risk AI systems. Article
14 addresses effective human oversight. Neither article prescribes one database
or consensus algorithm.

For an engineering team, however, the operational question is unavoidable:

Where is the control decision made, and can the system prove which policy,
evidence and accountable actor produced it?

Putting every request behind a cross-region consensus round would provide a
strong ordering point, but it can also make the governance layer the slowest
component in the request path. Avoiding the check is not acceptable. Pretending
that the network is free is not engineering.

The proposed split: local decision, serializable control record

The design separates the synchronous decision path from the durable control
record.

  1. A request is classified in its home region.
  2. A versioned policy bundle and the current control state are loaded locally.
  3. A deterministic evaluator returns allow, deny, or require_confirmation.
  4. The decision envelope is appended to an ordered control log.
  5. Only an allow result releases the external model request.
  6. Evidence and confirmation events are reconciled into the audit state.

The home-region rule matters because it gives every governed system one
authoritative write location for the synchronous decision. Replication can occur
outside the critical path while the ordered control record remains
serializable.

This is the property we want from a SLOG-inspired topology. We are not claiming
that the current Logik Systems production repository implements the SLOG paper,
and we will not use that name as a shipped-product claim until the topology and
benchmark are published.

AI request
    |
    v
home-region policy snapshot
    |
    v
deterministic evaluator ----> deny / confirmation
    |
    v allow
append decision envelope
    |
    v
external model API
Enter fullscreen mode Exit fullscreen mode

What is already implemented

The current product contains versioned evidence records, SHA-256 verification,
predecessor links (prevVersionId), snapshot-chain construction, recurring
confirmation state and audit exports.

A simplified evidence version is:

{
  "evidenceVersionId": "ev_0187",
  "sha256": "9d9f...3a2c",
  "prevVersionId": "ev_0186",
  "recordedAt": "2026-07-27T09:12:00Z",
  "controlId": "human-oversight"
}
Enter fullscreen mode Exit fullscreen mode

The digest protects the bytes of an evidence object. The predecessor reference
orders versions. A separate snapshot digest can commit to the normalized control
state:

snapshotHash[n] =
  SHA-256(
    canonical(snapshot[n])
    || snapshotHash[n-1]
  )
Enter fullscreen mode Exit fullscreen mode

Verification recomputes the digest from canonical input and checks the
predecessor reference. A mismatch is evidence of inconsistency; it is not
silently repaired.

That is a useful integrity property, but wording matters. A SHA-256-linked record
is not automatically immutable. Immutability also depends on key custody,
authorization, storage controls, retention and independent anchoring. Ed25519
signatures are a planned hardening step, not a current production claim.

What still needs proof

The pre-execution gate becomes a product capability only after four things are
measured and published:

  1. Fail-closed behavior: the model call is never released after a deny, timeout or unavailable policy snapshot.
  2. Determinism: identical canonical inputs and policy versions produce the same decision envelope.
  3. Ordering: concurrent decisions receive a reproducible order in the authoritative control log.
  4. Latency: p50, p95 and p99 overhead are measured by region, payload size, cache state and failure mode.

The latency target is an experiment, not a headline. We will publish numbers
only with the harness, environment, sample size and raw result artifact.

Why this is relevant to EU AI Act engineering

The Act does not say “use this architecture.” It does create a need for
operators to connect logging, oversight, responsibilities and evidence to the
actual system lifecycle.

A pre-execution gate can make that connection explicit:

  • the policy version becomes part of the decision record;
  • a required human confirmation can block release;
  • evidence lineage can be inspected independently;
  • audit exports can reproduce the control state at a point in time.

That is the boundary Logik Systems is building toward: not a folder of compliance
documents, but a control record that can be inspected and challenged.

Review request

We are looking for technical review of the boundary, not endorsement:

  • Which failure mode would break the ordering assumption?
  • Where should an independent anchor sit?
  • Which benchmark distribution would make the latency result credible?
  • What would you require before calling the decision record tamper-evident?

The implementation proof will follow the measurements.

Request a scoped written review through the controlled commercial path

Primary references

Top comments (0)