Technical architecture
AffixIO is verification infrastructure deployed as a thin API boundary. Your systems of record stay in place. AffixIO evaluates policy per request, returns signed allow or deny outcomes, and optionally anchors proof digests in a Merkle audit tree. This document describes planes, data flow, and integration placement for security review.
Architecture summary
AffixIO separates concerns across three layers so compromise of one plane does not automatically compromise the others. The verification plane is stateless by default: no standing customer profile cache at the verifier. Proof metadata and optional audit leaves provide replayable evidence without duplicating personal data across vendors.
Three-plane security model
| Plane | Responsibility | Examples |
|---|---|---|
| Control plane | Account management, API key issuance, policy configuration, billing, audit dashboards | RBAC, MFA on admin paths, scoped credentials |
| Verification plane | Stateless evaluation engines, yes/no verdicts, optional signed proofs | Noir circuits, identity rules, eligibility checks |
| Trust plane | Signing keys, proof verification, transparency, revocation guidance | ML-DSA attestation, public key publication, key rotation |
Signing keys for proof attestation are isolated from general application databases. See Security documentation for operational detail.
Typical request flow
- Your application, gateway, or agent prepares a minimised verification payload over TLS 1.2+.
- AffixIO authenticates the request and evaluates configured policy against supplied attributes or tokens.
- The verification engine runs applicable Noir circuits or identity rules.
- AffixIO returns allow or deny with proof_id, proof_digest, and optional attestation.
- Your system enforces the outcome and stores proof metadata per your retention policy.
- Optionally, proof digests append to the Merkle audit tree for independent inclusion verification.
Underlying PII, if entered upstream, is not persisted at the verifier under default settings. Customers remain responsible for lawful basis and transparency to data subjects.
Zero-knowledge proof pipeline
Policy evaluation can produce Noir zero-knowledge proofs via Barretenberg. The prover demonstrates conditions were satisfied without revealing underlying field values to downstream verifiers. Circuit catalogue includes yesno, identity/KYC mappings, and domain-specific circuits documented in the ZK circuit library paper.
Prove and verify are separate API operations. Verify submits the exact proof payload returned by prove to prevent field loss during handoff. Demo Web 4.0 normalises this path for operator testing.
Merkle audit anchoring
Audit leaves record proof digests, circuit identifiers, events, and timestamps in an append-only Merkle tree. Algorithm: sha256-sorted-pairs. Third parties verify inclusion via /v1/merkle/verify-proof without calling back into your systems.
Full design: Merkle tree audit architecture. Live reproduction: WP-036.
Post-quantum attestation
Long-lived decision records face harvest-now-decrypt-later risk. AffixIO supports NIST-aligned lattice signatures (ML-DSA-65, FIPS 204) on attested responses when requestAttestation is set. Public keys publish for customer verification libraries. Scheduled rotation uses overlap periods for zero-downtime trust store updates.
Reference: Post-quantum attestation whitepaper.
Offline and edge patterns
QR tickets and edge-issued credentials embed proofs at issue time. Gate scanners verify locally, enforce spent-proof logic, and reconcile when connectivity returns. The same primitives power API calls and edge scans. Not a separate product surface.
Venue pattern: Anti-scalping tickets. Sandbox edge flows: ticket edge issue and consume.
Stack placement
| Your system | AffixIO role | Example decision |
|---|---|---|
| Payment gateway | Pre-authorisation gate | Merchant or transaction eligibility |
| Core banking / treasury | Transfer check | Agent-initiated payment authorisation |
| IAM / IdP | Augmentation beneath IAM | Policy yes/no per request, not session replacement |
| KYC platform | Decision boundary | Signed outcome beside systems of record |
| AI agent runtime | Pre-action gate | Tool call or spend authorisation |
| Access control | Entry gate | Role and time-bound authorisation |
Multi-tenant isolation
Production workloads use logically separated environments from development and sandbox. Customer data paths segment to prevent cross-tenant access. Multi-tenant architectures employ strict identifier scoping on every query and cache key. Enterprise deployments may discuss dedicated environments and data residency during procurement.
What AffixIO is not
- Not an identity provider or session store
- Not a CRM, data warehouse, or customer profile platform
- Not a replacement for KYC, core banking, or case management systems
- Not a general-purpose AI model or chat interface
Patent pending GB2510622.0. System and Method for Stateless Binary Eligibility Verification Using Live External Data.