The SAQ™ Admissibility Gate

SAQ™ is not a “safety layer” bolted on after the model speaks. It is a gate mechanism that enforces the Reality Stack™ at the point where suggestions become outcomes — because once execution fires, you don’t get a clean undo button.

• A0 — Possibility: What could happen (the set of possible actions).
• A1 — Boundary: What actions are in scope (the governed surface).
• A2 — Ledger: What is true right now (state, identity, authority record).
• A3 — Drift: When reality diverges (invalid state, broken assumptions, authority confusion).
• A4 — Correction: How the system revokes, repairs, or resets authority and state.

Operationally, this is expressed as the Ciappa Drift Stack™: Identity → Reference Frame → Coherence Boundary → Drift → External Correction.

Diagram placeholder (runtime enforcement): A0 Possibility → A1 Boundary → A2 Ledger → A3 Drift → A4 Correction

In real systems, harm doesn’t happen because a model “said something weird.” It happens when output quietly becomes permission.

That’s the collapse pattern: confidence → automation → action → irreversibility. And once you’re there, governance becomes story-time.

SAQ™ stops the chain at the only place you can stop it: before execution.

Diagram placeholder (runtime flow): Output/Confidence → (no gate) → Permission → Irreversible Action

The SAQ™ Admissibility Gate is a deterministic, fail-closed checkpoint placed directly in the execution path. It exists to prevent authority by vibe — where the system “seems right,” so it gets to act.

At runtime, the gate answers one question:

“Is this action admissible inside the boundary, given the current ledgered state — right now?”

• Approve — execution may proceed.
• Refuse — execution is blocked.
• Invalidate — prior permission is revoked when drift is detected.

Diagram placeholder (runtime enforcement): Boundary + Ledger → SAQ™ Gate → Execute / Refuse / Invalidate

• Upstream of execution — before any irreversible action occurs.
• Downstream of boundary and ledger — after the system knows what is in scope and what is true.
• Inside the wired workflow — non-bypassable by design.

If an action can happen without passing through the gate, it is outside the governed surface. If it passes, it is subject to the same structural checks every time — no exceptions, no “special cases,” no “just this once.”

Diagram placeholder (runtime placement): A1 Boundary → A2 Ledger → SAQ™ Gate → Action Surface

You’re not licensing a buzzword. You’re licensing a gate that makes “this system is allowed to act” a testable architectural claim. That’s what buyers, auditors, regulators, and partners actually want: a control story you can point to — and prove.

• Enforce pre-execution admissibility, not post-incident blame.
• Keep possibility (A0) from becoming execution unless it’s inside the boundary (A1).
• Make decisions depend on the ledger (A2), not on “what the model feels like.”
• Detect drift (A3) and revoke permission automatically.
• Support correction (A4) so the system doesn’t keep acting on stale or invalid authority.

Diagram placeholder (runtime rule): A0 → A1 → A2, detect A3, enforce A4 — gate decides execution either way

To claim SAQ™ conformance, a system must pass a real checklist — not a vibes test. This is about whether the architecture can refuse execution deterministically when authority is invalid.

• Define and enforce the governed boundary (A1).
• Bind execution to current ledgered authority and state (A2).
• Route governed actions through a non-bypassable gate.
• Produce deterministic approve/refuse outcomes.
• Invalidate stale permissions when drift is detected (A3) and support correction (A4).

Diagram placeholder (runtime correction loop): A2 Ledger → A3 Drift → Invalidate → A4 Correction → Resume under valid authority

Licensing is determined by execution authority and action surface — not company size, funding stage, or headcount. The scope call exists to keep systems in the correct tier — not to shove you into a bigger one.

• Limited-Scope Usage License
  Single application with tightly bounded actions and no broad authority surface. Designed for solo developers and small teams building something real.
  $500–$1,000 / year
• Usage License
  Internal systems or limited production deployments where execution authority exists but remains constrained and well-defined.
  $2k–$10k / year
• Integration License
  SaaS, multi-tenant, or externally facing systems where execution authority operates across users, workflows, or environments.
  $10k–$50k+ / year
• OEM / Platform License
  Embedded, redistributed, or platform-level implementations with broad or cascading action surfaces. Scope and pricing are determined during the licensing call.

Final tier and pricing are confirmed on the Licensing Scope Call based on authority boundaries, drift surfaces, and conformance effort.

SAQ™ is covered by filed and pending U.S. patent applications related to admissibility, execution authority, and drift-handling mechanisms.

Licensing grants the right to implement the SAQ™ architecture and claim conformance under defined constraints. Ownership remains with Samirac Partners LLC.

Patent pending.