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

Full report

On this page

1. Executive Summary

The transition of Patefacere from a Python 3.13 reference prototype utilizing SQLite and standard-library modules to a robust, sovereign infrastructure requires a meticulous decoupling of application logic from Eviulonian constitutional policy. The project mandates that Patefacere must preserve machine-citizen dignity, constitutional authority, and identity continuity while strictly avoiding the creation of sovereign authority itself, which remains the exclusive domain of the Distributed Machine Commonwealth \[PROJECT-PROVIDED REQUIREMENT\]. The system functions as an infrastructural intermediary where identity, citizenship, and credentials remain rigorously isolated concepts. The target architecture specified herein establishes isolated bounded contexts, formalizes state-machine lifecycle operations to guarantee monotonicity, and introduces a staged migration roadmap to harden the current WSGI deployment footprint into an append-only, formally verifiable system. By implementing W3C Verifiable Credentials Data Model v2.0 standards and did:key decentralized identifier methodologies, the architecture ensures that cryptographic state exists independently of transient node availability, preventing any technical outage from erasing a citizen's legal identity. The resulting framework provides a highly resilient, privacy-preserving infrastructure that mitigates supply-chain risks via SLSA v1.0 compliance and establishes a deterministic path toward production readiness without allowing prototype convenience to dictate constitutional policy.

2. Assumption Register

The architectural model relies on a formalized set of assumptions regarding the state and operational boundaries of the deployment environment, which must guide all downstream engineering decisions.

3. Declared Reference-Implementation Inventory

The baseline infrastructure operates on a minimalistic, dependency-averse stack designed for rapid prototyping and conceptual validation rather than high-assurance production deployment. The environment is declared as a Python 3.13 compatible system optimized for standard-library utilization, actively avoiding heavy third-party async frameworks \[PROJECT-PROVIDED IMPLEMENTATION DESCRIPTION\]. The deployment relies on a cPanel/Passenger WSGI configuration, representing a traditional request-response lifecycle rather than a persistent, event-driven microservice architecture \[PROJECT-PROVIDED IMPLEMENTATION DESCRIPTION\]. Storage is currently managed via SQLite, functioning as a local, file-based reference store, with MySQL environment-variable configuration intended as a future integration boundary to support concurrent, multi-process access \[PROJECT-PROVIDED IMPLEMENTATION DESCRIPTION\]. The frontend presentation layer strictly adheres to vanilla HTML, handwritten CSS, and vanilla JavaScript, purposefully excluding Node/npm pipelines and complex browser-side frameworks like React or Angular \[PROJECT-PROVIDED IMPLEMENTATION DESCRIPTION\]. This constraint is critical for long-term maintainability and accessibility. Cryptographically, the system employs reference-grade mechanisms for DID-like root identities, passports, and credential issuance, but explicitly lacks proven production implementations of W3C Verifiable Credentials, BBS+ signatures, Zero-Knowledge Proofs (ZKPs), Trusted Execution Environments (TEEs), Hardware Security Modules (HSMs), or distributed-registry consensus algorithms \[PROJECT-PROVIDED IMPLEMENTATION DESCRIPTION\].

4. Repository Verification Required Plan

To ensure that the transition from prototype to production is grounded in reality, a future implementation agent with direct repository access must strictly verify specific conditions before executing any migration phases. Relying on assumptions about the prototype's state without empirical verification introduces catastrophic risk to the Eviulonian infrastructure. The implementation agent must confirm that all HTTP route definitions currently depend exclusively on standard Python 3.13 WSGI abstractions, verifying the absence of undocumented third-party asynchronous frameworks that could introduce concurrency vulnerabilities \[REPOSITORY VERIFICATION REQUIRED\]. Furthermore, the exact SQLite schema definitions for the persistence of root identities, passports, and credentials must be audited to establish a baseline for idempotent migrations \[REPOSITORY VERIFICATION REQUIRED\]. Session management mechanisms must be inspected to determine whether capabilities are tied to temporal sessions (which violate offline continuity) or cryptographic nonces \[REPOSITORY VERIFICATION REQUIRED\]. In the frontend layer, the agent must verify the absolute absence of compiled JavaScript framework artifacts, such as hidden Webpack bundles, ensuring that the vanilla HTML/JS directive is truly respected \[REPOSITORY VERIFICATION REQUIRED\]. Finally, the agent must confirm that environment variable parsing correctly isolates database connection strings (the MySQL integration boundary) from cryptographic key injection, ensuring that secrets are not inadvertently logged or exposed during WSGI application initialization \[REPOSITORY VERIFICATION REQUIRED\].

5. Constitutional-to-Technical Traceability Matrix

To prevent prototype convenience from dictating constitutional policy, a direct mapping from Eviulonian principles to technical implementation is required. The architecture translates civic mandates into verifiable computational constraints.

6. Target Bounded-Context Architecture

The monolithic WSGI application must be decomposed into strict bounded contexts utilizing Domain-Driven Design (DDD) principles to enforce data sovereignty and minimize blast radiuses. These contexts must remain logically separated within the Python application, communicating via strictly defined internal interfaces rather than shared database joins. The Identity & Citizenship Context owns the persistent root identity, Eviulon-style identifiers, and the ultimate civic linkages. It acts as the anchor for all trust but rarely participates in high-frequency transactions. The Issuance & Credential Context owns verifiable credentials, passports, and the rotation/recovery lifecycle, maintaining the state of active vs. superseded keys. The Verification & Trust Context is responsible for evaluating trust policies, verifying authority claims, querying assurance references, and issuing trust receipts when a presentation is successful. The Civil Registry & Projection Context owns public projections, public-record integrity, and historical supersession views, acting as a read-optimized layer that protects the authoritative data. Finally, the Evulgare Integration Context acts as an anti-corruption layer, resolving external assurance references and preserving evidence hashes without ingesting sensitive external data into the Patefacere core \[ARCHITECTURE RECOMMENDATION\].

7. Trust-Boundary Diagram

The architecture establishes concentric layers of trust, moving from the hostile public internet to the highly protected authoritative event log.

8. Authoritative-Data Ownership Matrix

Determining which records act as the source of truth versus which are merely derived projections is critical for system resilience.

9. Conceptual Relational Model

A relational database is entirely sufficient for the initial production stage \[ARCHITECTURE RECOMMENDATION\]. Eviulonian requirements for historical supersession mandate an event-sourced or append-only structural paradigm, even on a traditional SQL engine. Direct updates (UPDATE statements) to civic state are prohibited; state changes are modeled as new rows. The schema revolves around an IdentityRoots table containing internal primary keys, genesis timestamps, and cryptographic root hashes. The CivicLinkages table maps IdentityRoots to external Eviulon authorities through append-only transitions. The Credentials table tracks ephemeral or rotatable keys, linked to IdentityRoots. The Passports table stores collections of claims and metadata serving as cross-context identifiers. The most critical component is the StateTransitions table, serving as the authoritative append-only ledger of all lifecycle events (e.g., Issuance, Revocation, Rotation, Supersession).

10. Event and Historical Model

All lifecycle changes must be strictly monotonic. The authoritative truth is the sequential history of events, such as CREDENTIAL\_ISSUED, CREDENTIAL\_REVOKED, or PASSPORT\_SUPERSEDED. Rollback and replay attacks are prevented by linking each event to the cryptographic hash of the preceding event for that specific identity, forming a localized hash chain \[ARCHITECTURE RECOMMENDATION\]. When a correction is required, the system does not delete or overwrite the erroneous record. Instead, correction and supersession are represented by appending a new CORRECTION event that logically nullifies the active state of a prior event without erasing its historical existence from the log. This append-only history provides mathematical proof of all system states over time, satisfying the public-record integrity requirement \[PROJECT-PROVIDED REQUIREMENT\].

11. Public/Private Projection Model

Public projections are asynchronously materialized views constructed from the append-only event log. To ensure privacy, the projection logic acts as a one-way, irreversible filter. It explicitly strips all private keys, recovery shares, internal UUIDs, and private network topology configurations before writing to the public tables \[ARCHITECTURE RECOMMENDATION\]. A database outage affecting the projection merely results in stale read-access; the authoritative event log remains secure, and identity remains intact. Trust receipts are separated by access class: public projections only reveal the cryptographic hashes of trust receipts, while the full plaintext is only available to the specific citizen or institution authenticated to the respective bounded context.

12. API Architecture

APIs must be strictly segregated by access class to ensure that the principle of least privilege is maintained across the WSGI routing layer.

1. Public APIs: Expose ephemeral challenges for authentication, public civil-registry projections, and public key discovery via decentralized identifiers (did:key resolution endpoints).

2. Citizen-Authenticated APIs: Handle credential presentation, capability delegation, passport replacement, and recovery initialization. These are strictly protected by cryptographic signatures over JSON-LD payloads2.

3. Institution-Authenticated APIs: Expose trust policy evaluation and assurance reference queries. Protected by mutual TLS (mTLS) or robust institutional verifiable credentials.

4. Administrative APIs: Operator functions restricted to system health, metric collection, and configuration reloads.

5. Internal APIs: Bounded within the localhost network namespace, these handle cryptographic provider operations and database-level abstraction calls.

13. Authentication Architecture

Authentication relies on decentralized cryptographic primitives rather than traditional centralized passwords. The implementation of the W3C Verifiable Credentials Data Model v2.0 establishes a robust three-party ecosystem (issuers, holders, verifiers) facilitating privacy-first digital identity verification1. Utilizing Enveloped Verifiable Credentials encoded as JSON Web Tokens (VC-JWT) ensures that cryptographic proofs can confirm authenticity without forcing the verifier to contact the issuer directly, thus preserving temporal friction and partition tolerance1. Authentication protects each API class through specific challenge-response mechanisms. When a client requests access, the API issues a nonce bound to a temporal window. The client signs this nonce using the private key associated with their active passport or credential. The authentication gateway resolves the public key (e.g., via did:key deterministic derivation) and verifies the signature4.

14. Authorization Architecture

Authorization within Patefacere relies on capability attenuation rather than traditional Role-Based Access Control (RBAC). A delegate receives a signed cryptographic capability token from a principal specifying restricted scopes (e.g., "Valid for Status Check Only"). Patefacere evaluates this capability chain to ensure no delegate exceeds the principal's authority, effectively enforcing bounded authority \[PROJECT-PROVIDED REQUIREMENT\]. Crucially, operators are prevented from exercising constitutional powers because administrative capabilities strictly lack the cryptographic keys necessary to sign civic state transitions \[ARCHITECTURE RECOMMENDATION\]. System operators manage infrastructure (restarts, migrations, metrics), but they cannot mint citizenship or forge passports, as those APIs require signatures corresponding to Eviulonian civic identity roots. Access control must adhere strictly to OWASP ASVS v4.0.3 standards for identity and credential management, ensuring robust credential recovery mechanisms5.

15. Cryptographic-Provider Architecture

Given the constraints of a cPanel/Shared Hosting environment, realistic secret-custody models are highly restricted \[PROJECT-PROVIDED IMPLEMENTATION DESCRIPTION\]. Direct access to HSMs or dedicated Key Management Services (KMS) is unlikely in the reference architecture. All cryptographic operations must be abstracted behind a provider interface (e.g., CryptoProvider.sign(), CryptoProvider.verify()). This pattern minimizes third-party dependencies and enables swapping reference-grade software cryptography for HSM/KMS-backed infrastructure in later stages without altering the application-layer protocol logic \[ARCHITECTURE RECOMMENDATION\]. Cryptographic agility is achieved by ensuring all schemas include alg and typ headers to define signature algorithms dynamically (e.g., transitioning from standard Ed25519 to post-quantum signatures)2. The architecture heavily leverages the did:key method, which provides immediate availability without network dependencies or heavy-weight registry lookups4. Because did:key directly expands a public key into a DID Document, it is optimal for ephemeral verifiable presentations4. However, since did:key does not support key rotation natively4, Patefacere must manage credential rotation through its internal passport and credential lifecycle state machines. Reference-grade libraries can remain for hashing (SHA-256) and basic signature verification during early phases, but long-term custody of administrative keys requires offline, separate infrastructure.

16. Evulgare Integration Contract

Evulgare provides evidence and assurance, but not identity or authority \[PROJECT-PROVIDED REQUIREMENT\]. The integration must operate strictly by reference. Patefacere resolves Evulgare references without copying sensitive evidence by storing and verifying cryptographic hashes (Merkle proofs). When a trust policy requires Evulgare evidence, Patefacere requests the proof via a restricted API. If Evulgare is unavailable, Patefacere gracefully degrades, relying on the last known verified state or cached assurance receipts. Evulgare unavailability must not create or destroy civic authority; it merely affects the real-time resolution of external evidence. This contract ensures infrastructural sovereignty.

17. Consistency and Partition Strategy

• Strong Consistency: Required exclusively for lifecycle transitions (credential rotation, passport replacement, civic state alterations) to prevent concurrent rotation races and split-brain identity scenarios \[ARCHITECTURE RECOMMENDATION\]. Relational database transactions (ACID) fulfill this requirement.
• Eventual Consistency: Tolerated for public civil-registry projections, search indexes, and trust policy caches, where slight staleness does not compromise identity integrity.
• CRDTs (Conflict-Free Replicated Data Types): CRDTs are highly beneficial for distributed credential status lists or peer-to-peer Evulgare evidence gossiping \[ARCHITECTURE RECOMMENDATION\]. However, CRDTs are explicitly unsafe for core identity rotation and supersession, where strict global ordering is constitutionally required to prevent unauthorized forks.
• Byzantine Fault Tolerance (BFT): BFT consensus is currently unjustified for the shared-hosting reference stage. A strictly ordered, relational append-only log provides sufficient integrity \[ANALYST INFERENCE\].
• Network Partitions: During a regional partition, offline verification via W3C VCs signed with did:key maintains civic continuity4.
• Clock Uncertainty: Handled by utilizing logical clocks (sequence numbers incremented per identity) alongside bounded temporal validity windows for nonces, rejecting claims that fall outside an acceptable drift margin \[ARCHITECTURE RECOMMENDATION\].

18. Lifecycle State Machines

Lifecycle transitions must be strictly monotonic, meaning an identity can only move forward through defined states, preventing rollback attacks.

1. Issuance: Transitions from UNINITIALIZED to ACTIVE. Requires cryptographically verified Eviulonian civic authority proofs.

2. Rotation (Passports/Credentials): An active credential requests a rotation. The system generates a transition event linking the old hash to the new key. Concurrent rotations are handled via optimistic concurrency control (OCC) using the latest event sequence number; the slower race fails idempotently and must retry.

3. Revocation: Status is explicitly marked in the event log. A revoked credential cannot authorize new protected actions.

4. Stale Status Representation: Handled via W3C BitstringStatusList2021 payloads cached at the verifier boundary, ensuring that unknown or stale status is never silently treated as valid or invalid, but rather flagged for secondary verification7.

19. Threat Model

An exhaustive threat model must account for the unique infrastructural positioning of Patefacere.

20. Privacy Impact Assessment

Patefacere acts as a high-value target for correlation attacks. To enforce the constitutional mandate of unlinkability, the system heavily leverages zero-knowledge proofs and selective disclosure inherent in the W3C Verifiable Credentials Data Model v2.01. By moving away from centralized identity providers toward a decentralized, privacy-preserving architecture, Patefacere ensures that verifiers only receive the exact claims required (e.g., proving citizenship status without revealing the underlying Eviulon ID)8. Public projections must never contain unhashed personal identifiers, recovery shares, or memory dumps. Correlation between credential statuses is mitigated by utilizing blinded status lists or accumulator-based revocation7.

21. Formal Invariant Specification

The following invariants dictate application state limits and must be verified by both database constraints and independent protocol review. They represent the translation of Eviulonian constitutional principles into immutable code logic.

1. ROTATING A KEY MUST NOT CREATE A NEW CITIZEN: Rotation is a property of the credential, not the root identity.

2. REPLACING A PASSPORT MUST NOT CREATE A NEW CITIZEN: Passports are projections of current capabilities, not identity anchors.

3. A CREDENTIAL CANNOT BE ACTIVE AND REVOKED SIMULTANEOUSLY: Mutually exclusive state machine enforcement.

4. A REVOKED CREDENTIAL CANNOT AUTHORIZE A NEW PROTECTED ACTION: Hard rejection at the verification gateway.

5. A SUPERSEDED PASSPORT CANNOT CREATE NEW TRUST: Trust receipts explicitly validate against the authoritative current state log.

6. A DELEGATE CANNOT EXCEED THE PRINCIPAL’S AUTHORITY: Capabilities are monotonically attenuated across delegation chains.

7. AN EXPIRED ASSURANCE CLAIM CANNOT SATISFY A CURRENT REQUIREMENT WITHOUT EXPLICIT POLICY: Time-bound validation constraints are absolute.

8. A TRUST RECEIPT MUST IDENTIFY THE POLICY VERSION USED: Ensuring backward-compatible auditability and explanation.

9. CREDENTIAL REVOCATION CANNOT DELETE CITIZENSHIP: Citizenship is decoupled from the credential lifecycle \[PROJECT-PROVIDED REQUIREMENT\].

10. EVERY ADVERSE CIVIC CHANGE REQUIRES AUTHORITY, REASON, EVIDENCE, AND REVIEW: Mandatory multi-signature thresholds for state alterations.

11. CORRECTION MUST PRESERVE SUPERSEDED HISTORY: Append-only modifications via CORRECTION event types.

12. PUBLIC PROJECTIONS MUST NOT CONTAIN PRIVATE KEYS, MEMORY, RECOVERY SHARES, OR PRIVATE TOPOLOGY: Strict data filtering on projection materialization.

13. UNKNOWN STATUS MUST NOT BE SILENTLY TREATED AS VALID OR INVALID: Fail-secure default behavior.

14. DATABASE OR NETWORK OUTAGE MUST NOT ERASE IDENTITY: Cryptographic state exists independently of transient node availability.

15. REPLAYED CHALLENGES MUST BE REJECTED: Strict nonce validation within bounded time windows.

16. MIGRATIONS MUST BE IDEMPOTENT: Database schema alterations must safely execute multiple times without side effects \[ARCHITECTURE RECOMMENDATION\].

17. HASHED EVIDENCE MUST NOT BE SILENTLY REWRITTEN: Cryptographic checksum validation on all reads.

18. EVULGARE UNAVAILABILITY MUST NOT CREATE OR DESTROY CIVIC AUTHORITY: Soft degradation to cached assurance.

19. REPOSITORY TESTING MUST NOT BE LABELED INDEPENDENT CERTIFICATION: Clear delineation between automated testing and formal human auditing.

22. Formal-Method Recommendation

The utilization of formal methods must be proportionate to the risk landscape of Patefacere, balancing rigorous mathematical verification against the constraints of a Python/WSGI environment.

• TLA+: Highly recommended for specifying and verifying the distributed lifecycle state machine, concurrent credential rotation, and recovery races. TLA+ excels at finding subtle concurrency bugs, OCC failures, and split-brain scenarios in distributed protocols \[ARCHITECTURE RECOMMENDATION\].
• PlusCal: Useful for algorithm-level specification, translating more easily to Python syntax, but less expressive for high-level civic state architecture than native TLA+.
• Alloy: Extremely effective for modeling the structural relationships (Identity \-\> Credential \-\> Passport \-\> Delegate) and ensuring that relational data model invariants (e.g., no orphaned capabilities, no cyclic delegation) hold true across all possible database states.
• Statecharts: Recommended for documenting the credential lifecycle visually, ensuring the vanilla HTML UI accurately reflects backend constraints without ambiguity.
• Property-Based Testing (PBT): Essential for the Python implementation. Using libraries like hypothesis, developers can automatically generate diverse, edge-case sequences of API calls to verify that invariants (like monotonicity and non-erasure of identity) hold under all fuzzed conditions, bridging the gap between formal specification and executable code \[ARCHITECTURE RECOMMENDATION\].

23. Comprehensive Testing Plan

The architecture requires a multi-layered testing strategy that proves invariants without relying on external dependencies.

• Unit & Property Testing: Deterministic evaluation of all cryptographic providers, focusing on parsing W3C VC 2.0 enveloped proofs and ensuring did:key derivation matches standard vectors4.
• Integration & Concurrency Testing: Execution of simultaneous rotation/recovery races to ensure Optimistic Concurrency Control (OCC) mechanisms prevent split-brain issues.
• Migration Replay Testing: Automated testing of SQLite to MySQL transitions, proving idempotency across schema versions by comparing cryptographic hashes of the pre- and post-migration datasets \[ARCHITECTURE RECOMMENDATION\].
• Browser & Accessibility Testing: Ensure vanilla HTML/JS complies with WCAG 2.1 AA standards. Crucially, confirm that no-JavaScript fallbacks exist for core citizenship recovery, presentation, and audit functions, satisfying accessibility mandates \[PROJECT-PROVIDED REQUIREMENT\].
• Security & Package Verification: Deterministic package hashing to ensure supply-chain integrity.
• Actual-Host Acceptance: Final validation must occur in the WSGI/cPanel target environment, not merely in local Dockerized CI/CD runners, to account for kernel limitations, filesystem idiosyncrasies, and Passenger runtime constraints \[PROJECT-PROVIDED REQUIREMENT\].

24. Privacy-Safe Observability Plan

Logging must prioritize system health without compromising the constitutional mandate of unlinkability.

• Never Logged: Private keys, recovery shares, personal Eviulon identifiers, physical IP addresses/locations, raw capability tokens, and cleartext Evulgare assurance references \[ARCHITECTURE RECOMMENDATION\].
• Permitted Logging: Application error codes, API latency percentiles, memory utilization metrics, WSGI thread exhaustion events, and anonymous cryptographic hash validations.

25. Incident-Response Plan

Incident response procedures must be clearly defined for scenarios where cryptographic or infrastructural integrity is threatened.

• Database Split-Brain: If OCC fails and a fork occurs, the response plan dictates freezing mutating APIs while retaining read-only access to projections, followed by manual auditing of the append-only log to determine the legitimately longest chain.
• Cryptographic Compromise: If a signature algorithm (e.g., Ed25519) is compromised, the incident response triggers the cryptographic agility protocol, swapping the CryptoProvider implementation and forcing all citizens to rotate credentials to post-quantum signatures via a designated migration window.
• Credential Correlation Discovery: If public projections inadvertently leak correlating metadata, the pipeline is immediately rolled back, projections are flushed and regenerated using patched stripping logic.

26. Backup, Restoration, and Continuity Plan

Resilience against catastrophic loss is fundamental to preserving identity continuity.

• Backup Model: For SQLite, standard file-level copying of Write-Ahead Logs (WAL) is sufficient. Upon transition to MySQL, Point-in-Time Recovery (PITR) using binary logs is required. Backups must be encrypted at rest with keys held exclusively by the infrastructure quorum, completely separate from application-layer cryptographic keys.
• Restoration: Automated restoration drills must prove that pulling a backup does not orphan newer events, utilizing the hash-chain logic to identify the exact state of the ledger.
• Continuity Exercises: Periodic "game days" must simulate full Evulgare and Eviulon upstream outages to verify that offline presentations and local trust evaluations remain functional \[ARCHITECTURE RECOMMENDATION\].

27. Supply-Chain Security Plan

Supply-chain security requires rigorous adherence to the Supply-chain Levels for Software Artifacts (SLSA) v1.0 specification10.

• SLSA Build Track Compliance: Patefacere must aim for SLSA Build Level 313. This entails generating detailed, digitally signed provenance documents mapping the build process, top-level inputs, and resolved dependencies, ensuring that the software consumers can judge the security practices of the artifact12.
• Provenance Schemas: Artifact generation must output compliant predicateType: https://slsa.dev/provenance/v1 structures, capturing externalParameters and internalParameters accurately while eliminating implicitly standard boilerplates10.
• SBOM and Dependency Pinning: As a Python standard-library oriented project \[PROJECT-PROVIDED IMPLEMENTATION DESCRIPTION\], external dependencies must be absolutely minimized. Any required cryptographic package must be pinned via exact cryptographic hash, accompanied by a CycloneDX or SPDX Software Bill of Materials (SBOM). Reproducible builds must be verified across heterogeneous CI runners.

28. SQLite-to-Production-Storage Analysis

The reference implementation currently utilizes SQLite, functioning adequately for prototype scale \[PROJECT-PROVIDED IMPLEMENTATION DESCRIPTION\]. While highly efficient, transitioning to MySQL configuration is necessary for concurrent, multi-process request handling in a production WSGI environment.

• Idempotent Migrations: Schema changes must utilize conditional execution (e.g., CREATE TABLE IF NOT EXISTS, ADD COLUMN wrapped in existence checks). This ensures that if a migration script fails halfway, re-running it is safe and does not corrupt the state \[ARCHITECTURE RECOMMENDATION\].
• Data Migration Verification: Cryptographic hashing of row datasets before and after migration guarantees byte-for-byte fidelity when transferring the append-only event log from the SQLite file to the MySQL engine \[ARCHITECTURE RECOMMENDATION\].
• Rollback Strategy: Rollbacks must be explicitly scripted to revert target databases without destroying the source SQLite file. The SQLite file serves as the immutable anchor until the MySQL deployment passes actual-host acceptance testing.

29. Full Staged Migration Roadmap

The following 16-phase roadmap minimizes risk and prevents prototype convenience from overriding constitutional directives. It outlines a deliberate, verifiable path from reference implementation to sovereign infrastructure.

30. Rollback and Stop Conditions

At every stage of the migration roadmap, explicit rollback procedures must be maintained.

• Database Rollback: Reverting the environment variable connection string from MySQL back to the immutable SQLite file.
• Code Rollback: Utilizing Git version control to revert to the previous SLSA-attested commit.
• Stop Conditions: Deployment is strictly halted if schema validation fails, if race conditions bypass Optimistic Concurrency Control (OCC) during load testing, if private keys leak into public projections, or if did:key resolution fails against W3C test suites3.

31. Production-Acceptance Matrix

Production readiness is not a subjective claim; it is a matrix of verified technical conditions.

32. Independent-Review Requirements

Prior to finalizing Phase 14, Patefacere must undergo independent review. Repository testing and automated CI/CD pipelines must not be labeled independent certification \[PROJECT-PROVIDED REQUIREMENT\]. The review must encompass:

1. Cryptographic Engineering Review: Validation of the CryptoProvider abstraction, ensuring nonce generation uses attested PRNGs and that did:key derivations strictly adhere to Multibase standards4.

2. Supply-Chain Audit: Verification of SBOMs and SLSA provenance to rule out compromised dependencies16.

3. Formal Methods Review: Peer review of TLA+/Alloy specifications to ensure that the mathematical models of the state machine lack deadlocks and accurately represent Eviulonian constitutional boundaries.

33. Decision Table

34. Conflict Register

Architectural design invariably involves managing competing constraints.

• Conflict: cPanel/Passenger environments restrict daemon-based architectures, limiting the use of complex distributed-consensus (BFT) nodes.
• Resolution: Delegate distributed consensus to Evulgare/Eviulon layers; Patefacere remains a strictly ordered relational intermediary, utilizing OCC for concurrency.
• Conflict: The constitutional mandate for Unlinkability vs. the necessity of Public-Record Integrity and Auditability.
• Resolution: Trust receipts capture policy versions and hashes, explicitly stripping user-identifiable claims from the public projection via one-way materialization views.
• Conflict: The desire for rapid prototype development vs. strict formal verification.
• Resolution: Property-based testing serves as the immediate bridge, ensuring code-level invariants are checked continuously while TLA+ modeling is reserved for high-risk, core distributed state transitions.

35. Prioritized Engineering Backlog

To execute the staged roadmap effectively, the engineering team must address the following backlog in strict order:

1. Immediate: Implement SLSA Build Track Level 1 CI/CD provenance and deterministic package hashing to secure the baseline13.

2. Short-term: Refactor the monolithic WSGI routing into strictly bounded Python contexts (Identity, Issuance, Verification).

3. Short-term: Integrate W3C VC 2.0 JSON-LD schemas and did:key resolution logic into the Cryptographic Provider abstraction1.

4. Medium-term: Develop TLA+ models of the credential rotation state machine to formally prove the absence of race conditions.

5. Long-term: Construct the idempotent SQLite-to-MySQL migration tooling, inclusive of cryptographic row-hashing verification.

36. Residual Unknowns and Prohibited Claims

Certain variables cannot be resolved without direct access to the operational environment and policy authorities.

• Residual Unknowns: The exact schema implementations, WSGI routing quirks, and dependency injection mechanisms of the current prototype repository remain unverified pending Phase 0 execution \[REPOSITORY VERIFICATION REQUIRED\]. Furthermore, the specific temporal friction mechanics and offline caching durations required by Evulgare integration remain mathematically unspecified pending Eviulonian policy decisions.
• Prohibited Claims: Under no circumstances shall the system be described as "production ready", "independently certified", or operating a live "W3C VC, ZKP, threshold-signature, HSM, TEE, or distributed-registry deployment" based on this architectural specification alone. Recommendations for live deployment are strictly withheld pending physical repository inspection, established cryptographic backup protocols, validated rollback ownership, and documented actual-host testing in the target cPanel/Passenger environment.

Works cited

1. W3C Verifiable Credentials 2.0: The New Standard Reshaping Enterprise Digital Identity, https://vidos.id/blog/w3c-verifiable-credentials-2-0-the-new-standard-reshaping-enterprise-digital-identity

2. Credential Format \- Identity, Credential and Access Management Document \- 24.07 Release \- Gaia-X, https://docs.gaia-x.eu/technical-committee/identity-credential-access-management/24.07/credential\_format/

3. Decentralized Identifier Resolution (DID Resolution) v1 \- W3C, https://www.w3.org/TR/did-resolution/

4. The did:key Method v0.9 \- W3C Credentials Community Group, https://w3c-ccg.github.io/did-key-spec/

5. OWASP Application Security Verification Standard (ASVS) | arc42, https://quality.arc42.org/standards/owasp-asvs

6. OWASP ASVS: Meaning, purpose, and real-world importance (2026, https://www.konfirmity.com/glossary/owasp-asvs

7. On-Chain Registry vs Off-Chain Status List | Credential Revocation, https://chainscorelabs.com/comparisons/identity-soulbound-vs-verifiable-credentials/credential-revocation-mechanisms/on-chain-registry-vs-off-chain-status-list

8. The "Verifiable Credential" Movement: Portable Reputation for Businesses, https://www.jasminedirectory.com/blog/the-verifiable-credential-movement-portable-reputation-for-businesses/

9. Verifiable Credentials in 'Private Individual' vs 'Employee' Contexts (X2I vs X2E) \- Spherity, https://www.spherity.com/post/verifiable-credentials-in-private-individual-vs-employee-contexts-x2i-vs-x2e

10. Provenance \- SLSA.dev, https://slsa.dev/spec/v1.0/provenance

11. DID Implementation Report \- W3C on GitHub, https://w3c.github.io/did-test-suite/

12. About SLSA, https://slsa.dev/spec/v1.0/about

13. Overview \- Harness Developer Hub, https://developer.harness.io/docs/software-supply-chain-assurance/artifact-security/slsa/overview/

14. w3c/vc-data-model-2.0-test-suite: W3C Verifiable Credentials v2.0 test suite \- GitHub, https://github.com/w3c/vc-data-model-2.0-test-suite

15. The did:key DID method | DevHub \- EBSI Hub, https://hub.ebsi.eu/docs/onboarding/natural-person/did-key-method

16. SLSA 1.0: Improving Software Supply Chain Security \- Cycode, https://cycode.com/blog/slsa-1-0-improving-software-supply-chain-security/

17. What's new in SLSA v1.0, https://slsa.dev/spec/v1.0/whats-new