Building a Tamper-Evident State Machine for EU AI Act Compliance

Marti Soura Vamseekar — Tue, 04 Aug 2026 15:48:13 +0000

When a regulation like the EU AI Act dictates strict compliance controls for high-risk AI systems, software engineers face a fundamental challenge: How do we translate qualitative legal classifications into programmatic safeguards?

Relying on developers to fill out compliance questionnaires or tagging models in a static wiki creates a wide vector for silent failures. When risk metadata is decoupled from deployment pipelines, models can easily drift past regulatory boundaries without triggering mandatory control audits.

This post explores the engineering behind turning compliance from a static checklist into a programmatic state machine backed by a tamper-evident audit ledger using the open-source EU AI Assurance OS.

The Architecture: Code-Driven Risk States

To ensure repeatable classification, risk assessment must live in the active software pipeline. We structure this process around a strict state-transition pipeline:

[DRAFT_ASSESSMENT] -> [EVALUATING] -> [CLASSIFIED] -> [CONTROLS_BOUND] -> [VERIFIED_LOCK]

1. Deterministic Rule Assessment & Assisted Classification

Instead of manual evaluation, we define classification logic as version-controlled rules matching EU AI Act criteria. We use an assistive AI trace (grounded vector search over statutory control libraries via pgvector) to parse system intake payloads against regulatory text. This surfaces relevant control recommendations, though human compliance officers retain final signing authority.

2. Control Catalogs and Cryptographic Ledgers

Once a system hits CLASSIFIED, the engine binds mandatory controls from our Control Catalog to the release track. Each state change is appended to a hash-chained audit log. If a database record is altered out-of-band, the cryptographic chain invalidates, tripping an automated block in the CI release-gate contract.

3. Evaluation and HMAC-Signed Gates

Before models reach production, eval workers score model artifacts and data contracts. Results are pushed through durable worker queues, returning HMAC-signed callback tokens that confirm compliance before the deployment pipeline can proceed.

Get Involved

Landing & Live Demo: https://euassuranceai.souravamseekar.com
GitHub Repository: https://github.com/SVamseekar/eu-ai-assurance-os
Full Article: https://blog.souravamseekar.com/high-risk-is-a-workflow-label-not-a-meeting-vibe

Why Managers Still Lose the Dinner Rush on Three Tablets

Marti Soura Vamseekar — Tue, 04 Aug 2026 07:51:30 +0000

Designing a Multi-Tenant Restaurant OS: Unifying POS, KDS, and Aggregators

In multi-unit restaurant operations, the greatest engineering enemy is state fragmentation. When a restaurant relies on one proprietary terminal for in-house dining, separate tablets for delivery aggregators, and manual spreadsheets for inventory, operators face severe blind spots during peak volume hours.

This article outlines how we designed masova—a multi-tenant restaurant operating system that unifies POS tickets, kitchen displays, delivery aggregator orders, and fiscal-safe ledgers into a single, resilient control surface.

The Problem: Siloed State and Synchronous Bottlenecks

Standard restaurant setups suffer from distributed state divergence. If an aggregator order arrives while the local network drops or a terminal blocks waiting for an external payment gateway, the order state can be lost entirely from downstream kitchen displays.

To solve this, MaSoVa adopts an edge-first, decoupled architecture.

Core Architectural Patterns

Unified Order Normalization: All inbound payloads are normalized into a standard event format upon receipt. We use an append-only SQLite WAL file on the local LAN to transition orders reliably through deterministic states (RECEIVED -> LOCALLY_QUEUED -> PREP) without blocking on cloud confirmation.
Multi-Store Isolation: Using strict tenant key partitioning, each restaurant location maintains isolated boundaries for menus, staff permissions, and analytics, preventing cross-store data leaks.
Asynchronous Manager Dashboards: Background worker threads rollup transactions asynchronously to populate the manager control surface, ensuring high-frequency POS traffic never contends with administrative read queries.

AI Trace: Demand Forecasting Under Human Constraints

To assist with prep planning without risking inventory waste or hallucinations, MaSoVa includes a demand forecasting agent. The model predicts item-level prep quantities using historical sales data and seasonal trends, but its outputs are written to a staging table that requires explicit manager review and approval before becoming active kitchen tasks.

DEV Community: Marti Soura Vamseekar