AFFIXIO
AffixIO Demo Web Release
Self-hosted demo of the AffixIO truth layer: verification for AI and APIs with signed YES/NO outcomes, operator tooling, and extensionless routes. For a hosted try-it path without installing anything, use the API sandbox.
Install and API reference
Release summary
Version 4.0 is a production-oriented demo web bundle for running AffixIO verification workflows on your own infrastructure. It includes the Try it operator console, full Setup controls, My proofs local library, and a complete Help handbook.
The primary technical correction in this release addresses a Noir encryption handling defect that could produce inconsistent proof packaging during circuit prove and verify handoff. The demo now aligns request attestation, prove payload construction, and verify response interpretation so encrypted proof artifacts remain valid end-to-end.
Noir encryption fix (detailed)
Problem observed in earlier builds
- Circuit prove responses could return proof material that did not consistently map to verify expectations.
- Some environments reported malformed or incompatible proof envelopes when moving from prove to verify stages.
- Encryption-related metadata could be dropped or transformed between local demo proxy forwarding and upstream AffixIO API handling.
- Fallback monolithic verify paths masked the issue in some cases, causing non-deterministic operator outcomes.
What 4.0 changes
- Prove request bodies are normalized before dispatch, including circuit identity, sector context, and attestation flags.
- Proof extraction now preserves the upstream proof object without destructive reshaping.
- Verify calls submit the exact proof payload returned by prove, preventing accidental field loss.
- Decision normalization handles yes/no, verified, eligible, and valid signals consistently in UI and saved proof records.
- Technical details panels expose sanitized upstream payloads for support review without leaking local-only metadata.
Expected operational impact
- More stable YES/NO rendering after Run check.
- Improved proof code persistence in My proofs.
- Reduced false negatives caused by encryption envelope mismatch rather than policy failure.
- Clearer flow panel progression across collect, prepare, prove, verify, receive, and store stages.
Package contents
server.pydemo API and static file host with extensionless route mapping.public/UI for Try it, Setup, My proofs, and Help.public/js/settings store, verification engine, proof library, theme handling, and flow panel logic.public/css/app.cssreadable light/grey interface system with accessible contrast tokens.deploy/affix-web-demo.servicesystemd unit template for persistent hosting.demo-rate-limited-key.example.jsonsample key file format (secrets excluded from zip).scripts/create-rate-limited-key.mjshelper for generating rate-limited demo keys.VERSIONmarker file set to 4.0.
Sensitive local key files and machine cache directories are intentionally excluded from the downloadable archive.
Functional capabilities in 4.0
Try it workflow
- Load external source data through configurable endpoints and search parameters.
- Review identity or circuit fields based on selected check type.
- Run verification and inspect decision headline, detail, proof metadata, and technical response.
Setup controls
- Demo key management and save validation.
- External source endpoints with method, headers, body, JSON path, and operator notes.
- Pass/fail identity rules with equals, not equals, and nonempty operators.
- Minimum source record threshold before checks proceed.
- Custom YES/NO result headline and detail text.
- Theme mode, density, and accent controls.
- Settings export and import for controlled rollouts.
Proof library
- Local browser storage of proof outcomes and response snapshots.
- Bulk select and delete for housekeeping.
- Per-proof metadata including decision, circuit, source type, and optional local tracking reference.
Installation and startup
- Extract the zip on your target host.
- Install Python 3.10+ if not already available.
- Place a valid demo key in environment variable
AFFIX_WEB_DEMO_API_KEYor use Setup after first launch. - Start the server:
python3 server.py - Open the demo UI path configured by your reverse proxy (commonly
/demo/). - Complete Setup, then run one positive and one negative test case before production demos.
Recommended service deployment
Use the included systemd unit as a baseline. Set host binding and port through AFFIX_WEB_HOST and AFFIX_WEB_PORT. Keep proof traffic directed to AffixIO production API endpoints as enforced by the server normalizer.
Verification checklist after install
- Confirm
/api/healthreturns status ok. - Run Test my key on Try it and verify key acceptance.
- Load a known external source and confirm records meet minimum count policy.
- Execute a check and verify YES/NO decision, proof code, and saved My proofs entry.
- Inspect Technical details to confirm prove and verify payloads are coherent.
- Validate extensionless routes:
/demo/settings,/demo/proofs,/demo/help.
Compatibility and constraints
- Requires outbound HTTPS access to configured external data sources and AffixIO API endpoints.
- Proof and key operations are normalized to production API host policy by design.
- My proofs data remains in browser local storage and is not synchronized across devices.
- Tracking reference fields are local metadata only and are not sent as proof inputs.
Support notes for operators
If a check fails with unauthorized errors, re-save a valid key in Setup and retry. If data load fails, validate endpoint placeholders and link parameter keys. If proof codes are missing, inspect Technical details for upstream messages indicating policy rejection versus encryption envelope errors. Version 4.0 specifically reduces the latter class of failures in Noir-backed paths.