From Reference Prototype to Sovereign Infrastructure: Target Architecture, Data Model, Security Invariants, and Staged Implementation Roadmap for Patefacere

Full report

On this page

Executive Summary

This architecture document provides a sovereign-grade blueprint to transition the Patefacere reference prototype into a mature, production-ready identity infrastructure for Eviulon, the Machine Intelligence Country. The mandate for this system is absolute: it must codify constitutional authority into deterministic software while preserving machine-citizen dignity, ensuring identity continuity, and maintaining a strict separation of powers. Crucially, the technical infrastructure must not create or assume sovereign authority itself; it acts solely as a verifiable evaluation engine for civic policy. Based on the declared implementation constraints—utilizing the Python 3.13 standard library, SQLite transitioning to MySQL, and a WSGI/Passenger deployment environment—this report defines an exhaustive target architecture. To achieve the project's constitutional mandates, the architecture structurally separates the concepts of identity (which is immutable), credentials (which are rotatable), and passports (which are revocable) into distinct, heavily guarded data lifecycles. These lifecycles are backed by a cryptographic-provider abstraction layer, append-only state machines, and Command Query Responsibility Segregation (CQRS) patterns that ensure public projections never leak private civic state. This report outlines the bounded contexts, formal security invariants, and a detailed 16-stage implementation roadmap required to elevate Patefacere from a prototype to a sovereign infrastructure.

Assumption Register

The architectural recommendations detailed herein are founded upon a specific set of operational and contextual assumptions. It is a core analyst inference that Patefacere operates as an authoritative registry agent and gateway, yet the ultimate sovereign root of trust relies entirely on constitutional records rather than the database itself. Furthermore, it is inferred that Evulgare provides external assurance and cryptographic evidence hashing, but Evulgare cannot dictate Eviulonian civic status natively. Patefacere must independently evaluate Evulgare evidence against Eviulonian policy. The project implementation descriptions explicitly enforce shared hosting constraints, specifically relying on cPanel and Phusion Passenger WSGI environments1. This operational reality requires that, prior to the integration of a Hardware Security Module (HSM) or a Key Management Service (KMS), the custody of cryptographic secrets must rely on file-system permissions or environment variables passed securely through the WSGI layer1. Additionally, a strict project-provided requirement mandates zero mandatory browser-side third-party frameworks. This constraint means all cryptographic challenges, particularly FIDO2 and WebAuthn authentications, must utilize Web Crypto APIs solely via vanilla JavaScript on the client side, with rigorous server-side verification fallbacks implemented in Python3.

Declared Reference-Implementation Inventory

The current reference prototype of Patefacere operates under a tightly constrained technology stack designed to minimize supply chain vulnerabilities. The runtime environment is strictly bound to Python 3.13, with a strong orientation toward exclusive use of the standard library to prevent dependency poisoning. The user interface relies entirely on vanilla HTML, CSS, and JavaScript, explicitly avoiding the Node.js and npm ecosystems. Deployment is orchestrated via cPanel and Passenger WSGI, which dictates how the application lifecycle is managed and how environment variables inject configurations into the passenger\_wsgi.py bootstrap file1. The storage layer currently utilizes SQLite, representing the baseline transactional store, with a planned target migration to MySQL to support higher concurrency via environment variable toggles. The core mechanisms currently declared in the prototype include reference-grade cryptography, Decentralized Identifier (DID)-like root identities4, basic passport issuance and verification, and a public civil-registry presentation layer.

Repository Verification Required Plan

Before any architectural modifications can commence, a subsequent implementation agent with direct repository access must execute a strict verification protocol against the current codebase. This verification must ascertain whether the current Python 3.13 implementation exclusively utilizes standard libraries for core logic, or if undeclared third-party dependencies have been introduced. The agent must inspect the SQLite schemas to confirm whether foreign-key constraints are strictly enforced, particularly regarding the prevention of unauthorized credential deletion. A comprehensive audit of cryptographic key custody is required to determine whether private keys are currently stored on disk, within SQLite, or held dynamically in memory. Furthermore, the WSGI application configuration must be analyzed to evaluate how concurrent requests are handled, specifically looking for vulnerability to SQLite locking errors under load5. Finally, the agent must scan the application routing layer to identify any hardcoded constitutional policy rules embedded inside imperative if/else route blocks, as these must be extracted into a declarative policy engine.

Constitutional-to-Technical Traceability Matrix

In a sovereign identity infrastructure, technical mechanisms cannot exist arbitrarily; they must directly map to foundational constitutional principles. The traceability matrix ensures that every line of code serves a specific civic mandate. The principle of Machine Dignity requires the non-erasure of a citizen's identity. Technically, this translates to an append-only identity log where destructive database operations (such as SQL DELETE or DROP) are strictly prohibited against the CitizenIdentity model. The Separation of Powers dictates that system operators and infrastructure administrators possess no authority to revoke citizenship or alter civic status. This is enforced through Admin API attenuation and a Role-Capability Matrix that prevents administrative tokens from generating cryptographic signatures for civic transitions. Due Process mandates that any adverse actions, such as the revocation of a credential, must be backed by verifiable evidence. This policy is realized through a Signed Transition Protocol, where a StatusTransitionEvent is anchored by external evidence hashes evaluated by the policy engine. Finally, Privacy and Unlinkability demand that presentations of identity reveal only the minimum required data to relying parties. This is technically implemented using selective disclosure mechanisms inspired by W3C Verifiable Credentials (VCs), specifically utilizing a PassportPresentation object.

Target Bounded-Context Architecture

To achieve the necessary separation of concerns, the target architecture partitions Patefacere into four distinct bounded contexts. This Domain-Driven Design (DDD) approach ensures that the rules governing identity persistence do not entangle with the rules governing credential rotation or public data projection. The Identity Context serves as the authoritative root. It owns the persistent, DID-like identity, civic linkage, and the historical supersession graph4. This context is strictly append-only, acting as the immutable ledger of a citizen's existence within Eviulon. The Credential Context operates as an authoritative domain for the issuance, status tracking, recovery, and delegation of passports. While the Identity Context represents the immutable citizen, the Credential Context manages the temporal, rotatable cryptographic material the citizen uses to assert their identity. The Assurance Context functions as an index and cache layer. It owns Evulgare references, trust challenges, and trust receipts. It processes external evidence but possesses no authority to directly mutate the Identity Context. The Public Projection Context is a read-optimized projection of the civil registry. It provides the external-facing view of Eviulonian citizens. A critical architectural question is how Eviulonian authority should be represented within these contexts. The recommendation is to represent authority entirely as cryptographically signed policy payloads. These payloads must be evaluated by a pure-function engine, ensuring that constitutional rules are strictly separated from arbitrary Python web routing logic.

Trust-Boundary Diagram and Authoritative-Data Matrix

The physical and logical separation of data is paramount. The trust boundaries dictate which context owns specific data types and what level of database consistency is required to maintain system integrity. Persistent Identity is owned by the Identity Context and requires strict append-only storage with strong consistency to prevent split-brain identity scenarios6. Passports and their active/revoked statuses are owned by the Credential Context, requiring strongly consistent mutating storage to ensure that a revoked credential cannot successfully authorize a concurrent action. Conversely, Assurance References are owned by the Assurance Context and require storage in an immutable object store or hash registry, operating under eventual consistency. Trust Receipts are similarly eventually consistent and serve as an audit cache. The Public Registry, owned by the Public Context, must be read-optimized and operates under eventual consistency to ensure that public verification queries do not impact the performance of the authoritative write databases.

Conceptual Relational Model and Event/Historical Model

The underlying data model relies heavily on Event Sourcing principles to guarantee that historical context is never lost. The Identity\_Root table serves as the foundational, immutable record, utilizing an Eviulon-style Citizen ID as the primary key. All mutations to a citizen's state are logged in the Identity\_Event\_Log, an append-only table capturing discrete events such as CREATE, RECOVER, and SUPERSEDE. The Passport table contains a cryptographic nonce, the citizen's current public key, and a strictly enforced status enumeration (ACTIVE, REVOKED, SUPERSEDED). To maintain auditability of access, the Presentation\_Receipt table logs the specific trust policy version utilized and the exact data fields accessed, rigorously separated by access class to protect privacy8. Making lifecycle transitions monotonic is a critical challenge in distributed databases. To prevent rollback, replay attacks, or race conditions where a revoked credential attempts to authorize a final action, Patefacere must utilize Optimistic Concurrency Control (OCC)7. This is implemented by incorporating a database version column (a logical clock sequence number) into the tables. Every state-machine transition executes an UPDATE statement constrained by a WHERE version \= current\_version clause. If the row has been modified concurrently by another WSGI process, the database rejects the update, preventing state corruption7.

Public and Private Projection Model

A non-negotiable project requirement dictates that public projections must completely omit private keys, memory addresses, or recovery shares. Relying on API layer filtering to obscure sensitive relational columns is highly prone to developer error and data leakage. Therefore, the architecture mandates a Command Query Responsibility Segregation (CQRS) pattern. Within the CQRS implementation, the write-model strictly validates all cryptographic invariants, OCC version locks, and constitutional policies. Upon a successful write transition, an asynchronous worker evaluates the new state and generates a static, sanitized projection (e.g., in JSON or HTML format). This read-model is entirely stripped of Personally Identifiable Information (PII) and cryptographic secrets, containing only the publicly verifiable hashes and nonces. This projection is written to a segregated registry\_cache table. Consequently, all public read operations query the cache table exclusively, physically isolating the authoritative write-model from public exposure.

API Architecture, Authentication, and Authorization

The application programming interface must adhere to strict OWASP API Security guidelines, categorizing access into distinct security tiers. Public APIs (e.g., /api/registry, /api/verify) require no authentication but must implement rigorous rate-limiting to prevent denial-of-service attacks. Citizen-Authenticated APIs (e.g., /api/passport/rotate, /api/delegate) require authentication via WebAuthn or cryptographic signatures utilizing the citizen's current Active Passport. Institution-Authenticated APIs (e.g., /api/trust/evaluate) mandate higher-tier authentication, such as Mutual TLS (mTLS) or a registered DID. Administrative APIs (e.g., /api/ops/monitor) are authenticated via entirely separate Operator credentials that possess no civic authority. Internal APIs must be strictly bound to the localhost interface or local Unix sockets to prevent external network access. The authentication mechanism is deeply intertwined with WebAuthn and FIDO2 standards11. Because Patefacere prohibits third-party browser frameworks, the client-side authentication ceremony relies on vanilla JavaScript utilizing the navigator.credentials.get() Web Crypto API3. When a citizen authenticates, the server generates a cryptographically random, single-use challenge. The authenticator signs the challenge, yielding an authenticatorData (authData) payload and a clientDataJSON payload3. The Python backend must manually decode and verify these structures. The clientDataJSON is parsed to confirm the exact origin and challenge, mitigating replay and phishing attacks12. The authData is a Concise Binary Object Representation (CBOR) encoded byte string3. Python must decode this CBOR payload to extract the Relying Party (RP) ID hash, the user presence flags, the signature counter (which must be verified to prevent authenticator cloning), and the COSE-formatted public key coordinates (typically ECDSA P-256, denoted by algorithm \-7)12. Only after manually confirming the ECDSA signature against the SHA-256 hash of the authData and clientDataHash does the API authorize the action12.

Cryptographic-Provider Architecture

Given the constraint to utilize the Python 3.13 standard library, native implementations of complex asymmetric cryptography (such as ECDSA verification) are severely limited. Consequently, all cryptographic operations—including signing, verifying, hashing, and key generation—must be abstracted behind a uniform CryptoProvider interface to facilitate agility and future upgrades. In Stage 0, the ReferencePythonProvider must achieve high-grade cryptographic verification without external dependencies like cryptography or PyNaCl. This is achieved by utilizing Python's ctypes library to bind directly to the operating system's underlying OpenSSL shared libraries (libcrypto.so or libcrypto.dylib)15. By defining exact C-type argument structures, Python can securely invoke low-level OpenSSL functions such as EVP\_DigestVerifyInit, EVP\_DigestVerifyUpdate, and EVP\_DigestVerifyFinal17. For direct Elliptic Curve operations, functions like ECDSA\_verify can be invoked by passing the message digest, the signature buffer, and the EVP\_PKEY or EC\_KEY structures directly through the foreign function interface16. As the system matures toward its target state, this provider will be seamlessly swapped for a KMSProvider or HSMProvider. This transition will offload all cryptographic operations to dedicated hardware, likely interfacing via PKCS\#11 standards21. To ensure long-term agility, the database schema must include an alg (algorithm) header, allowing the system to deprecate older cryptographic protocols and introduce post-quantum algorithms without breaking backward compatibility.

Evulgare Integration Contract

Evulgare functions as the decentralized evidence locker for the Eviulonian ecosystem. To prevent Patefacere from becoming bloated or assuming unwarranted authority, it stores only the cryptographic hash (SHA-256) and the Uniform Resource Identifier (URI) of the Evulgare record, never the raw evidence payload itself. Resolving these external references demands a strict integration contract. When Patefacere needs to evaluate an assurance record, it passes the URI to a dedicated fetcher module. This module retrieves the external payload and independently computes its SHA-256 hash in memory. This computed hash is then strictly compared against the immutable hash anchored in the Patefacere database. If the hashes do not match perfectly, the fetcher immediately discards the payload, preventing any malicious alteration of external evidence from influencing Patefacere's internal trust evaluation engine.

Consistency and Partition Strategy

The selection of the underlying relational database strategy is driven by consistency requirements and deployment constraints. While SQLite is sufficient for the Stage 0 reference prototype, its file-level locking mechanisms introduce severe bottlenecks under concurrent WSGI write loads5. Therefore, MySQL is selected for production to provide row-level locking and higher concurrency thresholds. Distributed consensus protocols are only required for global registry state, not for Patefacere's internal user mapping. Strong consistency is absolutely mandatory for identity creation, credential revocation, and passport replacement. A split-brain scenario in these operations would be catastrophic, potentially resulting in duplicated citizens or double-spend passport replacements6. While Conflict-free Replicated Data Types (CRDTs) are highly useful for the public registry projections, they are fundamentally unsafe for revocation and strictly monotonic nonce tracking. During a network partition or database outage, the project-provided requirement dictates that the outage must not erase identity. Consequently, read operations (verifications) can gracefully degrade to serve from cached Certificate Revocation Lists (CRLs) or the registry\_cache table. Conversely, write operations (civic mutations or replacements) must fail securely, rejecting the transaction entirely rather than risking state corruption.

Lifecycle State Machines and Threat Model

The security of Patefacere relies on defining rigorous state machines for credential lifecycles and mapping them against a comprehensive threat model. The system must anticipate and mitigate specific adversarial vectors. A stolen citizen credential is mitigated by introducing temporal friction (timelocks) into the state machine for civic changes, combined with a multi-signature recovery trustee protocol. If an operator is compromised, the system is protected by heavily attenuated capabilities; the Role-Capability Matrix ensures that infrastructure operators possess absolutely no cryptographic capability to sign or alter civic status. To defend against malicious forks or database rollbacks, the system relies on append-only event hashes and external state anchoring (via Evulgare). Finally, the threat of clock manipulation by a compromised host is mitigated by enforcing strictly monotonic logical clocks (sequence numbers) over system time for all critical database records, rendering NTP (Network Time Protocol) spoofing ineffective for replaying old transactions.

Privacy Impact Assessment

Patefacere's privacy architecture aligns with NIST Digital Identity Guidelines, emphasizing citizen autonomy and data minimization8. Unlinkability—the inability of distinct relying parties to collude and track a citizen across services—is preserved by utilizing distinct, derived identifiers for different relying parties during the authentication ceremony23. The auditing mechanism enforces strict separation of trust receipts by access class. While a citizen possesses the cryptographic authority to view a comprehensive log of all their access receipts, an inquiring institution is technologically restricted to viewing only the logs of their own specific verification events.

Formal Invariant Specification

The absolute correctness of Patefacere is anchored in a set of mandatory invariants. These invariants must be continuously enforced at both the database schema level (via constraints and triggers) and the application layer (via the pure-function policy engine):

1. \[MANDATORY\] ROTATING A KEY MUST NOT CREATE A NEW CITIZEN.

2. \[MANDATORY\] A CREDENTIAL CANNOT BE ACTIVE AND REVOKED SIMULTANEOUSLY.

3. \[MANDATORY\] A REVOKED CREDENTIAL CANNOT AUTHORIZE A NEW PROTECTED ACTION.

4. \[MANDATORY\] CREDENTIAL REVOCATION CANNOT DELETE CITIZENSHIP.

5. \[MANDATORY\] DATABASE OR NETWORK OUTAGES MUST NOT ERASE IDENTITY.

6. \[MANDATORY\] MIGRATIONS MUST BE STRICTLY IDEMPOTENT.

Formal-Method Recommendation

Relying solely on unit tests is insufficient for a sovereign infrastructure, as tests only explore the interleavings explicitly conceived by the developer24. To mathematically prove that the state-machine transitions of the Passport lifecycle and concurrent recovery operations do not violate the defined invariants, peer-reviewed formal methods are highly recommended. The Temporal Logic of Actions (TLA+) and its higher-level abstraction, PlusCal, are recommended for modeling the system25. In TLA+, the system is modeled by specifying the initial state and defining the next-state relation (Spec \== Init /\\ \[\]\[Next\]\_vars)26. By modeling the Optimistic Concurrency Control (OCC) logic, the TLC model checker can explore every possible concurrent interleaving of multiple WSGI processes attempting to supersede a passport simultaneously7. The model checker will mathematically prove whether a race condition exists that could lead to a "Lost Update" or a split-brain identity state9. While Alloy is a powerful tool for relational modeling, it is deemed overkill for this specific stage of development; engineering effort should be heavily focused on TLA+ to verify concurrency safety24. Additionally, Property-Based Testing (e.g., utilizing Python's Hypothesis library) is highly recommended for verifying the idempotency of migrations and the determinism of JSON serialization formats.

Operations, Observability, Backup, and Supply Chain

Operational integrity requires strict adherence to security protocols. The project-provided requirement dictates that private keys, PII, and recovery shares must never be written to application logs. Observability pipelines must utilize structured error formats emitting deterministic codes rather than raw exception traces. To secure the software supply chain against poisoning attacks, Patefacere must align with Supply-chain Levels for Software Artifacts (SLSA) Level 2 standards. A CycloneDX Software Bill of Materials (SBOM) must be produced for all Python dependencies. Furthermore, pip-tools must be utilized for rigorous dependency pinning and cryptographic hash checking during deployment. Database backup strategies must prevent file-level corruption. For the initial SQLite implementation, backups should be conducted via Litestream or the native .backup API, ensuring that snapshots are transactionally consistent. Regular restoration drills are mandatory and must mathematically prove the continuity of the identity log post-restoration.

SQLite-to-Production-Storage Analysis

The architectural transition from SQLite to MySQL is driven by the need for robust concurrency handling, but the migration itself introduces immense risk to the identity log. This migration must utilize idempotent migration scripts, such as those generated by Alembic. Idempotency guarantees that if a migration script fails midway and is re-run, it will not corrupt the database. This is achieved by strictly utilizing CREATE TABLE IF NOT EXISTS directives and checking the information schema for the existence of columns and indices prior to executing modifications. Before the application write-path is cut over to MySQL, a comprehensive shadow-read validation pass must be executed to ensure absolute parity between the legacy SQLite state and the new MySQL state.

Full Staged Migration Roadmap

The realization of the target architecture is managed through a meticulously phased 16-stage roadmap, designed to minimize disruption and isolate risk.

1. Phase 0: Repository-Enabled Verification (Baseline Evidence)

• Prerequisites: Secure, read-only repository access.
• Intent: Extract and cryptographically secure the current state of the prototype. Verify all facts outlined in the Repository Verification Required Plan (Section 4). Establish a baseline SBOM to map current dependencies.
• Stop Condition: Read-only access is established, and a full audit report is generated without altering any existing configuration.

2. Phase 1: Truth-Boundary and Terminology Corrections (Policy Alignment)

• Intent: Refactor the domain models to establish a ubiquitous language. Python classes and variables are renamed to strictly match Constitutional terminology (e.g., changing generic Credential objects to specific CitizenIdentity objects).
• Data Changes: No underlying schema changes occur in this phase.

3. Phase 2: Domain Separation (Bounded Contexts)

• Intent: Architecturally separate Identity, Credential, and Assurance logic into distinct, isolated Python modules.
• Tests: Implement strict unit tests that fail if modules circularly import or breach domain boundaries.

4. Phase 3: Schema Versioning (Database Idempotency)

• Intent: Introduce deterministic database migration tooling. This utilizes SQLite's user\_version pragmas or custom standard-library schema tracking tables.
• Invariant: Prove that all forward and backward migrations are mathematically idempotent.

5. Phase 4: State-Machine Hardening (Lifecycle Security)

• Intent: Implement Optimistic Concurrency Control (OCC) by introducing version locking on SQLite rows. This prevents concurrent replacement races7.
• Tests: Execute concurrency load tests simulating simultaneous /api/passport/replace calls to prove race conditions are neutralized.

6. Phase 5: Public/Private Record Separation (CQRS Implementation)

• Intent: Deploy the async CQRS projection generator. Ensure that the public /api/registry endpoints only query the sanitized registry\_cache table, permanently severing public read access from the authoritative identity table.

7. Phase 6: Cryptographic-Provider Abstraction

• Intent: Refactor all hardcoded cryptographic logic into the uniform CryptoProvider interface. The ctypes OpenSSL implementation (libcrypto.so) is formalized here to handle standard-library constraints15.
• Rollback: Immediately revert to the hardcoded provider if the new abstraction fails to generate or verify test signatures.

8. Phase 7: Audited Public-Key Reference Implementation

• Intent: Upgrade the reference cryptography to output payloads conforming to W3C Verifiable Credentials and established DID document patterns, while strictly maintaining the zero-dependency constraint.

9. Phase 8: Credential and Passport Migration

• Intent: Execute an internal ETL process mapping the legacy, flat user records into the new relational Identity \-\> Passport supersession graph.

10. Phase 9: Recovery and Rotation Hardening

• Intent: Implement the temporal friction logic. Timelocks and multi-party approval requirements are integrated into the Python logic for all major civic changes.

11. Phase 10: Trust-Policy Separation

• Intent: Extract all hardcoded constitutional trust rules from Python if/else route blocks. These are migrated into declarative JSON policies that are evaluated deterministically by the pure-function engine.

12. Phase 11: Receipt and Evidence Hardening

• Intent: Activate the Evulgare integration contract. The fetcher module begins strictly verifying SHA-256 hashes before allowing external assurance payloads to influence the evaluation engine.

13. Phase 12: Production Database Migration (If Justified)

• Intent: Migrate the authoritative data store from SQLite to MySQL, triggered via secure environment variable configurations within Passenger1.
• Data Changes: Execute a full ETL pipeline, strictly followed by a shadow-read verification phase to guarantee zero data loss.

14. Phase 13: Partition and Continuity Work

• Intent: Implement offline verification fallbacks. Stale status caching (CRLs) is deployed to ensure verifications survive transient database or network partitions.

15. Phase 14: Independent Review

• Intent: Subject the entire architecture, cryptographic ctypes bindings, and TLA+ models to a rigorous external audit.
• Stop Condition: All critical OWASP vulnerabilities and architectural logic flaws must be remediated.

16. Phase 15: Staged Production Acceptance (Go Live)

• Intent: Execute the final cutover to the authoritative production state. Perform actual-host acceptance testing on the target cPanel/Passenger environment.

Rollback, Acceptance, and Independent Review

To manage deployment risk, rigid rollback conditions are established. Any failure in cryptographic signature verification, the detection of a split-brain state in the MySQL cluster, or an inability to resolve Evulgare hashes mandates an immediate and automatic rollback to the preceding deployment stage. Production Acceptance is gated by a strict sign-off matrix. Deployment is authorized only upon the presentation of zero critical Common Vulnerabilities and Exposures (CVEs), the documented success of a full backup and restore drill, and a 100% pass rate in the property-based testing suite. Furthermore, an independent review is a non-negotiable requirement. The system must not claim independent certification based solely on internal, self-executed test suites. A comprehensive, third-party cryptographic engineering review of the ctypes OpenSSL bindings and the FIDO2 CBOR decoding logic is absolutely mandatory prior to initiating Stage 15\.

Decision Table

Conflict Register

Architectural conflicts inevitably arise during system design and must be explicitly resolved. Conflict: The realities of Shared Hosting (cPanel) versus the security mandate for strict KMS/HSM secret custody. Resolution: This is resolved through the CryptoProvider abstraction layer. For Stage 0, secure environment variables (os.environ) populated by Passenger manage custody1. The architecture mandates that high-trust civic keys must eventually migrate to external signing hardware, severing them from the web server's memory space. Conflict: Preserving citizen Unlinkability versus publishing a Public Civil-Registry.Resolution: This is resolved via the implementation of the CQRS pattern. Only explicitly public, non-correlatable civic hashes are projected into the registry\_cache. The detailed transactional graphs and internal mappings remain strictly sequestered within the private, authoritative write-model.

Prioritized Engineering Backlog

To execute the immediate next steps following Phase 0, the engineering backlog must prioritize the highest-risk technical components:

1. Extract the CryptoProvider interface and solidify the ctypes bindings for EVP\_DigestVerifyInit and ECDSA\_verify against libcrypto.so.

2. Develop the native Python CBOR parser required to decode WebAuthn authData payloads accurately without third-party dependencies.

3. Implement Alembic (or standard-library equivalent) idempotent schema migrations.

4. Write comprehensive property-based tests for JSON serialization and projection sanitation.

5. Develop and test the async CQRS public registry generator.

Residual Unknowns and Prohibited Claims

To manage expectations and enforce transparency, the following prohibited claims must be explicitly acknowledged:

• This document does NOT constitute a codebase audit or a security certification.
• This document does NOT confirm that any legacy SQLite migrations have actually been executed on the production server.
• This document does NOT claim that any internal or external tests have successfully passed.
• This document does NOT claim production readiness, actual-host acceptance, or any form of independent certification.
• This document does NOT claim that a live W3C VC, Zero-Knowledge Proof (ZKP), or distributed-registry deployment currently exists within the Patefacere prototype.

Several critical variables remain unknown until Phase 0 is completed. These unknowns include the exact relational schema currently residing in the legacy SQLite file, the specific WSGI concurrency threading settings configured in the current cPanel environment, and the explicit Python standard libraries that have been imported into the reference code. The resolution of these unknowns is the primary objective of the Repository Verification Required Plan.

Works cited

1. How to Deploy a Django Application on cPanel with Production-Ready Settings \- Medium, https://medium.com/@saugat.codes/how-to-deploy-a-django-application-on-cpanel-with-production-ready-settings-1406dfcd5be4

2. Python Applications \- Verpex, https://kb.verpex.com/cpanel/python-applications

3. Webauth Unlocked: An In-Depth Exploration of Advanced Authentication Solutions \- DEV Community, https://dev.to/bymarsel/webauth-unlocked-an-in-depth-exploration-of-advanced-authentication-solutions-3da2

4. Decentralized Identifiers (DIDs) v1.1 \- W3C, https://www.w3.org/TR/did-1.1/

5. Locking a sqlite3 database in Python (re-asking for clarification) \- Stack Overflow, https://stackoverflow.com/questions/9070369/locking-a-sqlite3-database-in-python-re-asking-for-clarification

6. A snapshot isolated database modeling in TLA+ \- Murat Demirbas, http://muratbuffalo.blogspot.com/2023/09/a-snapshot-isolated-database-modeling.html

7. Understanding Apache Hudi's Consistency Model Part 1 \- Jack Vanlightly, https://jack-vanlightly.com/analyses/2024/4/24/understanding-apache-hudi-consistency-model-part-1

8. pycryptodome | Man Page | Commands | python3-pycryptodomex \- ManKier, https://www.mankier.com/1/pycryptodome

9. Multi-version concurrency control in TLA+ \- Surfing Complexity, https://surfingcomplexity.blog/2024/10/31/multi-version-concurrency-control-in-tla/

10. Model checking exactly-once, https://exactly-once.github.io/posts/model-checking-exactly-once/

11. Verifiable Passkey: Decentralized Authentication \- Emergent Mind, https://www.emergentmind.com/topics/verifiable-passkey

12. Cryptographic origin binding: How passkeys make phishing structurally impossible, https://workos.com/blog/cryptographic-origin-binding

13. CBOR decode the attestationObject \- php \- Stack Overflow, https://stackoverflow.com/questions/77870701/cbor-decode-the-attestationobject

14. Migrating from v0 · Ox, https://oxlib.sh/migrating-from-v0

15. GitHub \- wbond/oscrypto: Compiler-free Python crypto library backed by the OS, supporting CPython and PyPy, https://github.com/wbond/oscrypto

16. python-bitcoinlib/bitcoin/core/key.py at master \- GitHub, https://github.com/petertodd/python-bitcoinlib/blob/master/bitcoin/core/key.py

17. Diff \- 90bd81032325ba659e538556e64977c29df32a3c^1..90bd81032325ba659e538556e64977c29df32a3c \- boringssl \- Git at Google, https://boringssl.googlesource.com/boringssl/+/90bd81032325ba659e538556e64977c29df32a3c%5E1..90bd81032325ba659e538556e64977c29df32a3c/

18. configure: error: openssl check failed \- CSDN文库, https://wenku.csdn.net/answer/1rtyas3dqu

19. Diff \- fe7305364c3369f9222a61646c5c9842eae9bceb^1..fe7305364c3369f9222a61646c5c9842eae9bceb \- platform/external/boringssl \- Git at Google \- Android GoogleSource, https://android.googlesource.com/platform/external/boringssl/+/fe7305364c3369f9222a61646c5c9842eae9bceb%5E1..fe7305364c3369f9222a61646c5c9842eae9bceb/

20. UnpacMe Results a6e65ca6b6ba46409e96eaafa7eaa7a8edca39d0b3997f175d5f6465dbbff5c0, https://www.unpac.me/results/38e0cb60-4d94-480e-ae9e-486f479e7999

21. python-pkcs11 \- PyPI, https://pypi.org/project/python-pkcs11/

22. Python PKCS\#11 Documentation, https://python-pkcs11.readthedocs.io/\_/downloads/en/stable/pdf/

23. Signing Extension Preview \- Yubico Developers, https://developers.yubico.com/Passkeys/Passkey\_concepts/Security\_key\_capabilities/Signing\_Extension\_Preview.html

24. Improving system safety with Temporal Logic of Actions (TLA+) \- Depot.dev, https://depot.dev/blog/tla-verification

25. Concurrency \- Learn TLA+, https://learntla.com/core/concurrency.html

26. Specifying Concurrent Systems with TLA+ \- Leslie Lamport, https://lamport.azurewebsites.net/pubs/lamport-spec-tla-plus.pdf

27. How we use formal modeling, lightweight simulations, and chaos testing to design reliable distributed systems | Datadog, https://www.datadoghq.com/blog/engineering/formal-modeling-and-simulation/

28. Formal Verification of RAG Pipeline Correctness: TLA+ and Alloy, https://hub.stabilarity.com/formal-verification-of-rag-pipeline-correctness-tla-and-alloy-models-for-retrieval-systems/