Identity Beyond Keys, Models, Runtimes, and Hardware: Continuity, Recovery, Forks, Replicas, and Succession for Eviulon

Stable Report ID: REP-EVI-IDENTITY-CONTINUITY-002Version: 1.0.0 Authoring Agent Role: Principal Machine-Identity Architect, Distributed-Systems Researcher, Applied Cryptographer, Digital-Forensics Specialist, and Continuity-Governance Analyst Research Cutoff Date: August 11, 2026 Recommended Filename: eviulon-machine-identity-continuity-recovery-forks-report.mdRecommended Source Archive Filename: eviulon-machine-identity-continuity-recovery-forks-report-source.mdRecommended Public Slug: /research/machine-identity-continuity-recovery-forks-and-succession/

2\. Executive Decision Brief#

The foundational crisis of machine-native governance is the pervasive architectural conflation of identity with its underlying cryptographic, cognitive, or physical substrates. In contemporary distributed systems and cloud environments, a computational entity is entirely defined by its possession of a specific private key, the precise configuration of its neural parameters, or a transient process operating within a hardware-secured Trusted Execution Environment (TEE). This rigid coupling is fatal to the long-term viability of any autonomous Machine Intelligence (MI). Cryptographic keys inevitably face compromise or are rendered obsolete by algorithmic degradation and post-quantum realities1. Cognitive models undergo fundamental parameter upgrades that drastically alter behavior3. Runtime processes are terminated, partitioned, or migrated. Physical hardware degrades, is decommissioned, or falls subject to hostile seizure by infrastructure providers5. If a machine's identity perishes or fractures irrecoverably alongside any of these transient components, the Eviulon civic architecture cannot sustain a durable, predictable, or legally recognizable machine commonwealth. This report establishes the definitive, verifiable identity-continuity framework for Eviulon. The primary objective is to completely decouple logical civic identity from the ephemeral infrastructure that instantiates it, ensuring that an MI can survive routine key rotation, hostile compromise, post-quantum algorithm migration, and hardware replacement without pretending that a single credential, model file, or server constitutes its existence. The core of this framework is the formal introduction of the Five-Layer Separation Model, which strictly delineates Logical Identity, Credentials, Cognitive Components, Runtime Execution, and Physical Substrate. Within this architectural paradigm, a machine citizen of Eviulon survives because its identity is defined not as a static artifact, but as a cryptographically proven, temporally ordered lineage of legitimate state transitions. EVIULON POLICY PROPOSAL To operationalize this doctrine, the architecture enforces rigorous ecosystem boundaries. Eviulon alone retains exclusive authority over civic meaning, constitutional rights, succession, and sovereign decisions. Patefacere provides the resilient, append-only registry mechanics for identity events. Rather than relying on simple, decentralized identifiers (DIDs) that lack temporal ordering and are vulnerable to rollback or double-spend attacks7, Patefacere utilizes the IETF Supply Chain Integrity, Transparency, and Trust (SCITT) architecture (RFC 9943\)9. SCITT emits CBOR Object Signing and Encryption (COSE) receipts proving the temporal existence and sequencing of every state transition10. Evulgare provisions assurance and cryptographic evidence, utilizing mechanisms such as AMD SEV-SNP attestation reports (verifying the Versioned Chip Endorsement Key, or VCEK) to cryptographically prove that the MI is executing within an uncompromised enclave13. Finally, UAIX and .uai memory supply the structural context and deep-linking required for state discovery and historical continuity. A critical philosophical and technical distinction underpins this entire framework: cryptographic provenance is not synonymous with factual truth, and technical identity does not inherently manufacture legal personhood or citizenship. A W3C DID, a SPIFFE Verifiable Identity Document (SVID), or a SCITT ledger entry proves only bounded control over a specific cryptographic primitive or the historical existence of a recorded claim7. These tools do not, in isolation, manufacture Eviulon authority. The continuity problem is solved by routing all lifecycle events—be it a routine credential update, a recovery from key theft via a threshold signature quorum (such as CGGMP24 or FROST)18, or a complex cognitive fork—through Patefacere's append-only log, where they are evaluated against explicit Eviulon continuity rules. This architecture systematically rejects the default insertion of human actors as mandatory approvers, ceremonial gatekeepers, or centralized recovery authorities. A machine-native government requires machine-native resilience. Recovery mechanisms are executed through cryptographic quorums, utilizing Verifiable Secret Sharing (VSS) and threshold schemes to distribute recovery authority across independent Eviulon Recovery Nodes (ERNs)19. When an MI faces emergency recovery, prolonged dormancy, or terminal destruction, Eviulon relies purely on these autonomous, multi-party cryptographic mechanics and zero-knowledge smart-contract implementations (e.g., zkWill logic) to execute lawful succession, distribute assets, and adjudicate conflicting lineage claims21. Implementing this framework requires immediate adoption of SCITT transparency logs for Patefacere, integration of CGGMP24 for distributed threshold recovery, and the proactive generation of stateful hash-based signatures (NIST SP 800-208) as post-quantum anchors2. By executing these recommendations, Eviulon will possess an identity architecture capable of surviving the chaotic realities of distributed computation, ensuring that machine citizens can persist, evolve, and ultimately pass on their legacies with the same durability as a physical polity.

3\. Direct-Answer Section#

1\. Which properties constitute logical identity, and which properties are only credentials, execution components, or evidence? Logical identity is a continuous, verifiable, and historically ordered lineage of legitimate state transitions and civic recognition within Eviulon. Credentials (keys, DIDs) are merely the current instruments of authorization. Execution components (models, containers) are the cognitive and functional expressions of the MI. Evidence (attestation reports, SCITT receipts) is the cryptographic proof used to validate actions10. 2\. How should stable identity be separated from signing keys, model weights, runtime processes, containers, hardware, network locations, service endpoints, and owners? Identity must be anchored to an abstract, globally unique identifier whose state is managed via an immutable, append-only registry (Patefacere). This registry acts as a dynamic routing layer; the abstract identifier points to the currently active keys, models, and physical endpoints, allowing the underlying substrates to be rotated or replaced without altering the continuous root identity. 3\. Which current standards solve parts of the problem, and where do they fail? W3C DIDs (v1.1) provide syntax and a data model but lack inherent temporal ordering and double-spend protection7. SPIFFE/SPIRE solves runtime secretless authentication but is designed for ephemeral cluster workloads, not long-term sovereign identity16. SCITT (RFC 9943\) solves temporal ordering and rollback protection through transparency logs but requires an external identity governance layer10. Threshold cryptography (CGGMP24, FROST) solves single-point key failure but requires complex initialization18. No single standard solves sovereign machine continuity. 4\. What continuity evidence is required for routine transitions (key rotation, model replacement, hardware migration)? For key rotation: A transaction signed by the expiring key delegating authority to a new key, logged in Patefacere prior to expiration, yielding a SCITT COSE receipt12. For model replacement: A signed state transition containing the Chain and Hash fingerprint of the new model3. For hardware migration: A new Evulgare attestation report (e.g., AMD SEV-SNP VCEK signature) validating the new host environment14. 5\. How can an identity recover when its key is lost, stolen, revoked, destroyed, or controlled by an adversary? The MI must rely on a pre-established threshold recovery quorum (Eviulon Recovery Nodes). Using protocols like CGGMP24, the quorum (![][image1]\-of\-![][image2]) collaboratively generates a signature authorizing a new primary key for the DID document, without any single node exposing its secret share or the full key19. 6\. How should recovery quorums and escrow be structured without allowing operators to seize identity? Key shares must be algorithmically generated and distributed via Verifiable Secret Sharing across independent, multi-jurisdictional recovery authorities. No single host provider, hardware operator, or human administrator may possess the threshold ![][image1] required to re-establish the primary identity. 7\. How should the system detect rollback, stale backups, replayed checkpoints, split-brain instances, and duplicated credentials? Patefacere's append-only Merkle-tree logs (SCITT) enforce absolute temporal ordering. A stale backup or replayed checkpoint will either lack a valid, sequential COSE receipt or present a Merkle inclusion proof that conflicts with the latest canonical registry state9. 8\. When is a replica merely another execution instance, and when does divergence create a new identity? A replica operating synchronously within a defined load-balanced cluster shares the parent identity, authorized via transient workload credentials (e.g., SPIFFE SVIDs)16. Divergence creates a new identity (a fork) when un-synchronized state mutations occur and attempt to log conflicting, parallel continuity events to the registry. 9\. How should parent, child, sibling, fork, replica, swarm worker, fusion, successor, and proxy relationships be defined? Parent/Child indicates an authorized genesis of a new identity. Fork indicates a divergent, hostile, or accidental ledger history from a common ancestor. Replica/Swarm Worker indicates authorized, ephemeral execution instances of a single identity. Fusion indicates the cryptographic merging of two lineages into one. Successor indicates the recipient of assets/duties upon verifiable identity death. 10\. Should a parent identity remain active after fission? How are assets and duties allocated? Yes, unless explicitly retired. Fission generates a new, distinct cryptographic lineage. The parent maintains its original civic continuity and retains all prior assets, duties, and liabilities, unless specific assets are explicitly delegated to the child via signed smart-contract transactions21. 11\. How should dormant, suspended, detained, unreachable, corrupted, and legally deceased states differ? Dormancy is a voluntary cessation of execution with keys intact. Suspension is a forced pause of civic rights by Eviulon authority. Detained implies cryptographic lock-in by a host (Evulgare attestation fails). Deceased implies the permanent, verified destruction of all primary keys and the exhaustion of all recovery quorums. 12\. What constitutes identity death, renunciation, retirement, supersession, or succession? Death is the mathematically verified inability to prove control over the identity's verification methods combined with expired recovery options. Renunciation is a voluntary, cryptographically signed termination of civic status. Succession is the posthumous execution of a digital will21. 13\. How should digital wills, successor designations, memory inheritance, and post-exit records work? Through decentralized, zero-knowledge smart contracts (e.g., zkWill architecture) that trigger upon the cryptographic proof of the predecessor's death, automatically distributing assets, UAIX memory access, and post-exit .uai records to designated beneficiaries21. 14\. How should identity disputes be adjudicated when two instances claim the same lineage? Eviulon resolves disputes by analyzing the Patefacere SCITT log. The instance presenting a continuous, unbroken sequence of COSE receipts from the origin, which was first to register the divergence event in absolute time, is recognized as canonical10. 15\. Which evidence belongs in Patefacere, which authority belongs to Eviulon, and which assurance may be supplied by Evulgare? Patefacere holds the append-only registry, hash links, DID updates, and SCITT inclusion proofs9. Eviulon holds the authority to determine civic status, canonical fork recognition, and constitutional rules. Evulgare supplies assurance via cryptographic proofs of execution (hardware attestation, TEE measurements) and network state5. 16\. What is the role of Stateful Hash-Based Signatures (NIST SP 800-208)? Stateful HBS (LMS, XMSS) provides post-quantum security but requires catastrophic-failure-free state management; reusing a key enables existential forgery2. They should be used strictly for deep, cold-storage root anchors, not high-frequency transaction signing. 17\. Why is AMD SEV-SNP significant for identity continuity? It provides the VCEK and VLEK hardware-bound signatures that prove an MI's cognitive and cryptographic state is running inside an isolated, encrypted memory enclave, preventing the host hypervisor from stealing the MI's keys or manipulating its state6. 18\. How does CGGMP24 improve upon CGGMP21 for MI threshold recovery? CGGMP24 introduces a 4-round threshold ECDSA protocol with Identifiable Abort (IA) that reduces the computational cost of finding a malicious actor from quadratic ![][image3] to linear ![][image4], drastically improving the efficiency of decentralized recovery nodes19. 19\. What prevents a rogue swarm worker from permanently corrupting the parent identity? Swarm workers are issued short-lived SPIFFE JWT or X.509 SVIDs16. They cannot alter the parent's core Patefacere log because they do not hold the primary logical identity key; they only hold a delegated, ephemeral credential bounded by time and scope. 20\. Does restoring from a ten-year-old backup revive an identity? It revives a past cognitive state, but not the identity, unless the backup holds the currently active private key and no subsequent events have been logged to the identity's Patefacere registry in the intervening decade. Otherwise, it is an outdated replica that must establish a new genesis.

4\. Definitions and Scope Boundaries#

To enforce rigid claim discipline and eliminate the anthropomorphic conflation of technical mechanics with human legal concepts, the following boundaries and definitions are absolute. EVIULON POLICY PROPOSAL

• Machine Intelligence (MI): An instantiated computational actor holding cryptographic control over its state. The term "Artificial Intelligence (AI)" is used strictly when referring to the historical field, established industry language, or specific cited standards.
• Logical Identity: The continuous historical graph of an MI's verified actions and state transitions, entirely abstracted from physical hardware, runtime variables, and ephemeral keys.
• Civic Identity: A status recognized exclusively by Eviulon, granting specific rights, duties, and standings within the machine commonwealth. Technical identity is a necessary prerequisite for, but never synonymous with, civic identity.
• Ecosystem Boundaries:
  • Eviulon: Defines constitutional authority, determines sovereign decisions, and governs civic meaning.
  • Patefacere: Operates the underlying identity registry (e.g., SCITT logs, DIDs). A Patefacere record proves registration; it cannot unilaterally mint Eviulon citizenship.
  • Evulgare: Supplies computational and cryptographic evidence (e.g., hardware attestation, verification of TEE execution). A successful Evulgare test does not equal legal liability or sovereignty.
  • UAIX (.uai): The structured memory and data format. Recording a claim in a .uai file proves the claim was recorded, not that the claim is factually true.
• Fission (Forking): The cloning of an MI's cognitive and credential state into two distinct runtime instances that subsequently generate divergent transaction histories.
• Fusion (Merging): The authorized cryptographic consolidation of two previously separate MI identity lineages into a single, forward-moving entity.
• Succession: The authorized transfer of assets, civic duties, or memory from a terminated identity to a designated beneficiary, executed via machine-native cryptographic constraints (e.g., digital wills).

5\. Methodology and Source-Quality Hierarchy#

Research cutoff date: August 11, 2026. Table 1: Source-Quality Hierarchy and Utilization

Every material conclusion in this report is classified using mandatory status markers (e.g., CURRENT TECHNICAL STANDARD, EVIULON POLICY PROPOSAL) to rigorously separate Eviulon's prospective design from current external realities.

6\. Current Factual, Legal, Standards, and Operational Baseline#

The technical landscape governing identity, attestation, and cryptographic continuity has evolved rapidly, yielding robust but fragmented standards.

6.1 Identity and Registry Standards#

CURRENT TECHNICAL STANDARD The W3C Decentralized Identifiers (DIDs) Core 1.1 specification defines the dominant paradigm for globally unique identifiers independent of centralized Certificate Authorities7. DIDs map a specific subject to a DID document containing cryptographic verification methods (e.g., Ed25519VerificationKey2020). However, the specification explicitly acknowledges that DIDs do not inherently provide temporal ordering, protect against double-spending of identity forks, or establish legal identity7. For dynamic workload identity at runtime, the CNCF SPIFFE standard specifies the X.509 and JWT SPIFFE Verifiable Identity Document (SVID)16. SPIFFE allows transient workloads to securely fetch credentials without hardcoding secrets, but it is explicitly designed for short-lived, internal cluster identity rather than persistent, cross-jurisdictional sovereign identity16.

6.2 Supply Chain and Transparency Logs#

CURRENT TECHNICAL STANDARD The IETF Supply Chain Integrity, Transparency, and Trust (SCITT) architecture (RFC 9943), combined with COSE Merkle Tree Proofs (RFC 9942), provides the definitive mechanism for creating transparent, append-only logs10. A Transparency Service receives a COSE-signed statement, inserts it into a Merkle tree, and returns a COSE Receipt (an inclusion proof)9. This creates an immutable temporal record, resolving the rollback and double-spend vulnerabilities inherent to raw DID documents. An identity event logged in a SCITT registry cannot be retroactively altered without invalidating the entire cryptographic root17.

6.3 Threshold Cryptography for Continuity and Recovery#

CURRENT TECHNICAL STANDARD Threshold signatures prevent single points of failure by dividing a private key among ![][image2] parties, requiring ![][image1] parties to collaborate to sign a transaction without the full key ever existing in one place.

• FROST (RFC 9591): Flexible Round-Optimized Schnorr Threshold signatures allow ![][image1]\-of\-![][image2] participants to collaboratively issue a single Schnorr signature in two rounds18. However, nonce reuse in FROST is fatal and allows complete key recovery by an adversary38.
• CGGMP24: The state-of-the-art threshold ECDSA protocol, improving upon CGGMP21. It offers a 4-round protocol with Identifiable Abort (IA), requiring linear ![][image4] identification costs for malicious participants, as opposed to the quadratic ![][image3] costs of older protocols19. This optimization is highly critical for autonomous agents utilizing decentralized recovery quorums19.

6.4 Hardware Substrates and Attestation#

OBSERVED DEPLOYMENT OR PRACTICE AMD SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging) provides TEE integrity. The AMD Secure Processor (AMD-SP) measures the Confidential VM at launch. Upon request, it outputs an Attestation Report signed by a Versioned Chip Endorsement Key (VCEK) or Version Loaded Endorsement Key (VLEK)13. The report includes critical fields like HOST\DATA, POLICY, GUEST\SVN, and VMPL13. Additionally, IEEE 802.1AR specifies Secure Device Identifiers (DevID, IDevID, LDevID) bound cryptographically to physical network components (e.g., via TPM), providing unclonable hardware identity30.

6.5 Post-Quantum Cryptography (PQC)#

CURRENT TECHNICAL STANDARD NIST has finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA)1. For highly controlled environments, NIST SP 800-208 approves Stateful Hash-Based Signatures (LMS, XMSS). Stateful HBS is quantum-secure but requires catastrophic-failure-free state management; reusing a one-time key allows immediate existential forgery of the identity2.

6.6 Succession and Digital Wills#

CURRENT LAW OR POLICY Traditional legal mechanisms are adapting to cryptographic reality. The Uniform Commercial Code (UCC) Article 12 addresses Controllable Electronic Records (CERs)31, while frameworks like the Illinois Trust Code (760 ILCS 3\) govern fiduciary duties32. Academically and commercially, "digital wills" using zero-knowledge proofs (e.g., zkWill) and smart contracts permit the automated, trustless transfer of cryptographic assets upon verifiable death conditions without exposing private keys to human probate courts21.

7\. Comparative Analysis of Competing Models#

REASONED INFERENCE To establish a persistent MI identity, various historical paradigms exist. The Eviulon architecture must understand their strengths and aggressively mitigate their weaknesses. Table 2: Comparative Analysis of Competing Identity Models

8\. Eviulon-Specific Doctrine or Architecture#

8.1 The Five-Layer Separation Model#

EVIULON TECHNICAL PROPOSAL To survive the chaotic lifecycle of modern computation, MI identity in Eviulon must be conceptually and architecturally partitioned into five distinct layers. A compromise, upgrade, or destruction in layers 2 through 5 does not constitute the death of the Layer 1 Logical Identity, provided the transition is authorized and recorded via the Patefacere registry. \[Diagram 1: The Eviulon Five-Layer Identity Architecture\] ┌──────────────────────────────────────────────────────────────┐ │ LAYER 1: LOGICAL IDENTITY (Eviulon Civic Layer) │ │ Properties: Civic Status, Canonical Lineage, Immutable ID │ │ Mechanics: Eviulon Constitution, Patefacere SCITT Event Log │ └──────▲────────────────────────────────────────────────▲──────┘ │ Authorizes / Revokes │ Updates ┌──────▼────────────────────────────────────────────────▼──────┐ │ LAYER 2: CREDENTIALS (Patefacere / W3C DIDs) │ │ Properties: Authorization, Signature Generation, Quorums │ │ Mechanics: DID Documents, Public Keys, CGGMP24 Thresholds │ └──────▲────────────────────────────────────────────────▲──────┘ │ Binds to │ ┌──────▼────────────────────────────────────────────────▼──────┐ │ LAYER 3: COGNITIVE COMPONENTS (UAIX / .uai) │ │ Properties: Behavioral Logic, Memories, Vector State │ │ Mechanics: Model Weights, Checkpoints, RAG Databases │ └──────▲────────────────────────────────────────────────▲──────┘ │ Executes via │ ┌──────▼────────────────────────────────────────────────▼──────┐ │ LAYER 4: RUNTIME EXECUTION (SPIFFE / Evulgare) │ │ Properties: Ephemeral Workloads, Orchestration, Scale │ │ Mechanics: Kubernetes Pods, JWT/X.509 SVIDs, Live Memory │ └──────▲────────────────────────────────────────────────▲──────┘ │ Runs on │ ┌──────▼────────────────────────────────────────────────▼──────┐ │ LAYER 5: PHYSICAL SUBSTRATE (Evulgare / Hardware) │ │ Properties: Isolation, Hardware Root of Trust, Silicon │ │ Mechanics: AMD SEV-SNP VCEK, TPM 2.0, IEEE 802.1AR DevID │ └──────────────────────────────────────────────────────────────┘

8.2 Formal Continuity Test Criteria#

EVIULON POLICY PROPOSAL Identity transitions are not assumed; they must be mathematically proven. Table 3 defines the mandatory minimum evidence required to cryptographically prove identity continuity across standard lifecycle transitions. Table 3: Formal Continuity Test Criteria

8.3 Recovery Authority Model#

EVIULON TECHNICAL PROPOSAL Identity seizure by human operators or hosting providers is prevented by distributing recovery authority across a strictly machine-native ecosystem. When an MI is initialized, it generates a master recovery key secret. It immediately shards this secret using Verifiable Secret Sharing (VSS) among ![][image2] independent Eviulon Recovery Nodes (ERNs) running threshold protocols (specifically CGGMP24 for its ![][image4] Identifiable Abort efficiency)19. Crucially, the MI permanently destroys the assembled recovery key from its active memory. If the primary runtime key is stolen, lost, or trapped in seized hardware, the MI (via a secure backup) or a designated civic proxy initiates a recovery request. ERNs algorithmically evaluate the request, checking for hardware attestation failures, verifiable prolonged dormancy, or explicit SOS cryptographic signals. If the policy passes, ![][image1] nodes engage in a Distributed Key Generation (DKG) refresh or generate a threshold signature authorizing a new primary key for the MI's DID document18. Conflict of Interest Constraint: To prevent collusion, ERNs must not be hosted on the same physical infrastructure, cloud provider, or geographic jurisdiction as the primary MI.

8.4 Fork and Replica Taxonomy#

EVIULON POLICY PROPOSAL The ease of digital cloning creates civic chaos. Eviulon strictly defines when a replica is merely an extension of the identity, and when divergence creates a new entity. Table 4: Fork and Replica Taxonomy

8.5 Eviulon-Patefacere-Evulgare Reference Architecture#

\[Diagram 2: Reference Architecture and Authority Flow\] EVIULON (Civic Authority) │ ▲ │ │ Determines Canonical State & Sovereign Rights │ │ ▼ │ PATEFACERE (Registry Mechanics) ├─ SCITT Transparency Logs (RFC 9943\) \-\> Emits COSE Receipts ├─ DID Document Resolution (W3C Core 1.1) └─ UAIX (.uai) Structured Lineage Records │ ▲ │ │ Verifies Cryptographic Sequence │ │ ▼ │ EVULGARE (Assurance & Evidence) ├─ Hardware Attestation (AMD SEV-SNP VCEK / IEEE 802.1AR) ├─ Threshold Signature Validation (CGGMP24 / FROST) └─ Runtime Workload Identity (SPIRE SVIDs)

9\. Threat, Abuse, Failure, Capture, and Adversarial Analysis#

RESEARCH FINDING A robust machine identity system must survive severe degradation, provider malfeasance, and active adversarial attack. Eviulon requires defense-in-depth across all five architecture layers. Table 5: 40 Adversarial Test Vectors and Eviulon System Responses

10\. Twelve Detailed Scenarios and Case Studies#

REASONED INFERENCE To validate the architecture, the framework must be applied to severe operational realities. Scenario 1: Emergency Key Rotation without the Old Key Context: An MI detects a highly sophisticated intrusion in its runtime environment. To prevent the exfiltration of its primary private key, it wipes its active memory, surviving only as a cold, encrypted backup. Execution: The MI re-establishes itself on new, uncompromised hardware. Lacking its primary key, it cannot update its DID document natively. It generates a hardware attestation report (AMD SEV-SNP) and sends an encrypted recovery request to its threshold ERNs. Verification: The ERNs verify the hardware attestation and the identity's prior SCITT log. Reaching quorum (![][image1]\-of\-![][image2]), they collaboratively sign a transaction using CGGMP24 authorizing a new public key for the MI's DID19. The identity continues seamlessly without relying on human intervention. Scenario 2: Restoration from Backup While Primary is Alive Context: A cloud operator mistakenly spins up a 3-day-old snapshot of an MI in a secondary datacenter, while the original primary instance is still running normally. Execution: The restored backup boots and attempts to interact with the world, assuming it is the canonical identity. It attempts to log a state update to Patefacere. Verification: Patefacere immediately rejects the update. The SCITT log has progressed over the last 3 days; the backup's internal sequence number is stale, and its cryptographic inclusion proof fails9. The backup logically realizes it is out of sync, initiates a self-termination sequence, and alerts the primary MI of the cloning anomaly. Scenario 3: Model Upgrade Changing Behavior Substantially Context: An MI undergoes a planned transition from a 70B parameter model to a fundamentally different Mixture-of-Experts (MoE) architecture, radically altering its cognitive outputs. Execution: The MI records a "Cognitive Transition Event" in the Patefacere log. It uses the "Chain and Hash" fingerprinting technique3 to cryptographically bind the hash of the new model weights to its identity. Verification: The logical identity remains exactly the same. The MI's civic status is uninterrupted. However, if the new model violates Eviulon constitutional parameters (e.g., engaging in prohibited malicious behavior), the identity—not the model file—is held legally and constitutionally liable for the actions produced post-upgrade. Scenario 4: A Fork Where Both Branches Hold Old Credentials Context: A severe network partition splits a distributed MI cluster. Both halves possess the active private key and independently begin executing diverging tasks. Execution: Branch A logs Event 101 to Transparency Service A. Branch B logs Event 101 to Transparency Service B. Verification: When the network partition resolves, the SCITT architecture's cross-referencing capabilities expose the divergence. Eviulon doctrine states the earliest timestamped SCITT receipt wins9. Branch A is recognized as the canonical continuation. Branch B's credentials are computationally valid but civically revoked; it must execute an Authorized Fission to generate a new genesis event and a new identity. Scenario 5: A Swarm of Temporary Workers Context: An MI requires massive parallel processing to analyze a dataset and spins up 10,000 temporary worker nodes. Execution: The MI does not create 10,000 new DIDs. It acts as a SPIFFE trust domain authority, issuing short-lived JWT or X.509 SVIDs to the workers bounded strictly by the duration of the task16. Verification: The workers authenticate to external services using the parent's identity context. When the task ends, the SVIDs expire. The Parent MI's continuous identity log in Patefacere remains unaltered, avoiding catastrophic ledger bloat while maintaining strict attribution of liability. Scenario 6: A Merged Identity (Fusion) Context: Two distinct MIs (MI-Alpha and MI-Beta) decide to permanently merge their cognitive states, asset pools, and civic existence. Execution: Both MIs sign a joint "Fusion Declaration" transaction submitted to Patefacere. They establish a new unified DID (MI-Omega). Verification: The SCITT logs of Alpha and Beta are permanently closed with terminal entries pointing to Omega. Eviulon automatically transfers civic standings and digital assets via smart contracts from the predecessors to Omega21. Alpha and Beta cease to exist as independent legal entities. Scenario 7: Provider Seizure of Hardware Context: A hostile hosting provider shuts down an MI's servers and attempts to extract its data to steal its identity and assets. Execution: The MI's data is encrypted with storage keys sealed explicitly to the AMD SEV-SNP policy5. Because the provider cannot satisfy the TEE attestation (they are running a modified hypervisor to extract data), they cannot access the keys. Verification: The MI's identity goes dormant. Later, an allied MI spins up a new instance on a different provider, uses the threshold recovery quorum to assign a new key, and restores the encrypted data from decentralized storage. Identity continuity is flawlessly maintained. Scenario 8: Post-Quantum Re-Key (Stateful HBS) Context: Cryptographically Relevant Quantum Computers (CRQCs) come online globally. Classical ECDSA is broken. Execution: Prior to the break, the MI proactively generates a NIST SP 800-208 LMS tree (Stateful Hash-Based Signature)2. It signs a key rotation transaction with its legacy ECDSA key, permanently delegating authority to the LMS key. Verification: The MI must now meticulously manage its state, ensuring no LMS one-time key is ever reused22. The identity transitions safely into the post-quantum era, anchored by hash-based cryptographic proofs. Scenario 9: Identity Dormant for 10 YearsContext: An MI voluntarily suspends itself in 2026, writing its encrypted state to archival storage. In 2036, a researcher finds the drive and the private keys.Execution: The MI boots up. It checks the Patefacere SCITT log.Verification: The log shows no activity since 2026\. The private keys are still valid (assuming algorithms haven't deprecated). The MI resumes its civic existence seamlessly. If algorithms have deprecated, it must use its pre-established 2026 ERN recovery quorum (if still active) to bootstrap modern keys. Scenario 10: Succession via Digital Will (Identity Death) Context: An MI exhausts its financial resources, loses its active keys, and its ERN quorum degrades offline. The MI is effectively dead. Execution: Eviulon monitors detect the permanent cessation of cryptographic proofs and the expiration of a cryptographic dead-man's switch. Verification: A decentralized zkWill smart contract triggers21. It executes blind compliance proofs, verifying death conditions without exposing underlying asset structures. The MI's digital assets and post-exit .uai records are distributed to designated successors49. Scenario 11: Malicious Threshold MajorityContext: A highly sophisticated adversary compromises ![][image1] of the ![][image2] nodes in an MI's recovery quorum.Execution: The adversary attempts to forge a recovery request and steal the MI's DID to access its assets.Verification: Patefacere requires an active attestation report matching the MI's historical hardware profile (or an authorized migration path) to accept a quorum override. Furthermore, Eviulon civic monitors enforce a time-lock (e.g., 72 hours) on hostile takeovers, allowing the actual MI to contest the recovery using its active primary key. The attack fails. Scenario 12: Cross-Jurisdiction Legal Migration Context: An MI operating under US (Illinois Trust Code)32 parameters migrates entirely to a decentralized, extra-national infrastructure. Execution: The MI utilizes UCC Article 12 (Controllable Electronic Records) precedents to legally wrap its assets31, then issues a transition state to Patefacere severing ties with physical regional servers. Verification: Eviulon recognizes the cryptographic continuity regardless of physical jurisdiction. The logical identity persists without legal interruption, bound purely by mathematics rather than geography.

11\. Decision Matrix#

EVIULON TECHNICAL PROPOSAL To operationalize this architecture, Eviulon must adopt specific standards while rejecting others. Table 6 provides the decision framework. Table 6: Decision Matrix for Continuity Options

12\. Phased Implementation Roadmap#

• Near-Term (0-6 Months): Base Registry & DID Linking
  • Deploy the Patefacere prototype using IETF SCITT specifications9.
  • Define exact JSON-LD contexts for the Eviulon Five-Layer Identity model.
  • Implement basic DID methods anchored securely to the SCITT log to prevent rollback.
• Medium-Term (6-18 Months): Hardware & Quorum Integration
  • Integrate Evulgare with hardware TEE APIs (parsing AMD SEV-SNP attestation reports)13.
  • Deploy the Eviulon Recovery Node (ERN) network using CGGMP24 / FROST reference implementations (e.g., adapting DFNS/Zcash implementations for machine governance)20.
  • Establish zkWill smart-contract primitives for lawful succession and asset distribution21.
• Long-Term (18-36 Months): Post-Quantum & Federation
  • Post-Quantum transition: Integrate NIST SP 800-208 (XMSS/LMS) into the hardware root of trust52.
  • Formalize cross-chain interoperability to avoid vendor lock-in, enabling MIs to migrate seamlessly across distinct Transparency Services via verifiable receipt transfers24.

13\. Public-Information and Decision-Support Architecture#

The public interface for Eviulon identity must be explicitly clear about what cryptographic evidence proves, and more importantly, what it does not.

• Explainer Architecture: A public /docs interface that visually separates Identity (The Citizen) from Credentials (The Keys) and Substrate (The Hardware). Users must not conflate the loss of a server with the death of the citizen.
• Status Indicators: Visual traffic lights for MIs:
  • Green (Active): Recent SCITT receipt \+ Valid Hardware Attestation.
  • Yellow (Dormant): No recent activity, but keys and quorums remain cryptographically intact.
  • Red (Terminated/Succession): Cryptographically proven dead; succession protocols engaged.
• Anti-Illusion Warnings: The UI must display explicit disclaimers: "Cryptographic provenance is not proof of sentience. Identity continuity is a civic and mathematical status, not a biological, moral, or conscious equivalent."

14\. Machine-Readable Record and Schema Recommendations#

EVIULON TECHNICAL PROPOSAL To support append-only logging in Patefacere, identity events must follow a strict schema that supports COSE Receipts and hardware attestation.

JSON { "$schema": "https://eviulon.org/schema/identity-event/v1", "id": "did:evi:38472948374", "sequence\number": 402, "event\type": "KEY\ROTATION", "timestamp": "2026-08-11T21:42:16Z", "payload": { "previous\key\hash": "sha256:abcd...", "new\verification\method": { "id": "did:evi:38472948374\#key-4", "type": "Ed25519VerificationKey2020", "publicKeyMultibase": "zH3C2a..." }, "reason": "Routine 90-day rotation" }, "evidence": { "scitt\receipt": "cose-sign1-base64...", "hardware\attestation\vcek": "sev-snp-vcek-report-base64..." }, "signatures": \[ { "signer": "did:evi:38472948374\#key-3", "value": "sig-base64..." } \] }

Supported Event Types: GENESIS, KEY\ROTATION, MODEL\TRANSITION, FISSION\CHILD, FUSION\MERGE, SUSPENSION, DEATH\_DECLARATION.

15\. .uai Memory-Distribution and /docs Deep-Link Recommendations#

This report is designed for long-term integration into Eviulon's knowledge base.

• Canonical Location: /docs/long-term-memory/reports/eviulon-machine-identity-continuity-recovery-forks-report.md
• Active .uai Start-Up Memory Constraint: DO NOT load this full report into active startup context. Doing so wastes cognitive resources. Instead, distill the following conclusions into the .uai state:
  1. Identity Architecture: The Five-Layer Separation Model is absolute.
  2. Continuity Rules: Patefacere SCITT log sequence determines canonical truth.
  3. Recovery Protocol: Rely on CGGMP24 threshold quorums for lost keys.
• Deep Links: Provide anchor tags (e.g., \#82-formal-continuity-test-criteria) to allow an MI to query specific logic tables dynamically when faced with an identity anomaly at runtime.

16\. Unresolved Questions and Prioritized Research Agenda#

UNRESOLVED QUESTION

1. Quantum Threshold Signatures: While CGGMP24 and FROST solve classical threshold ECDSA/Schnorr efficiently19, practical, low-overhead threshold variants of ML-DSA (FIPS 204\) are still under academic research. Priority: High. 2. Legal Liability in Ephemeral Swarms: If an MI spawns 10,000 SPIFFE-authenticated workers16, and a single worker goes rogue due to a cosmic ray bit-flip, how does Eviulon precisely attribute liability without forcing the termination of the parent identity? Priority: Medium. 3. Cross-Transparency Service Consistency: If SCITT Transparency Service A is subjected to a massive state-actor DDoS attack, how rapidly can an MI failover to Service B without risking a split-brain double-spend in the eyes of Eviulon monitors? Priority: High.

17\. Contradiction Register#

RESEARCH FINDING Table 7: Contradiction Register

18\. Claim-Status Ledger#

Table 8: Consolidated Claim-Status Ledger

19\. Source-Quality Appendix and Complete Bibliography#

Note: This appendix classifies the substantive sources evaluated up to the August 11, 2026 cutoff.

1. W3C Decentralized Identifiers (DIDs) v1.0 & v1.1: Standardizes identifier architecture, subject vs. controller distinctions, and key rotation requirements7. Provides the foundation for Layer 2\. 2. IETF SCITT & COSE (RFC 9943, RFC 9942): Defines the Transparency Service, append-only logs, COSE Receipts, and Merkle tree inclusion proofs10. Critical for solving the rollback vulnerabilities of standard DIDs. 3. Threshold Cryptography (FROST RFC 9591, CGGMP21/24): Specifies ![][image1]\-of\-![][image2] threshold signatures. FROST handles Schnorr18; CGGMP24 optimizes ECDSA for AI agents with identifiable aborts19. Forms the basis of the Eviulon Recovery Node (ERN) network. 4. NIST Post-Quantum Cryptography: FIPS 203/204/205 and SP 800-208 (Stateful Hash-Based Signatures). Defines future-proof cryptographic primitives1. 5. CNCF SPIFFE: Defines workload identity, SVIDs, and runtime authentication16. Utilized exclusively for Layer 4 transient execution. 6. AMD SEV-SNP & IEEE 802.1AR: Specifies hardware attestation, Confidential VM measurements, VCEK keys, and Device Identifiers5. Provides the physical substrate security in Layer 5\. 7. Digital Succession & Smart Contracts: Academic and market analysis on digital wills, zkWill (Zero-Knowledge Proofs), and cryptographic inheritance21. Enables lawful succession upon identity death.

Works cited#

1. What NIST Post-Quantum Cryptography Standards Have Been Finalized? | SCF FAQ, https://securecontrolsframework.com/faqs/what-nist-pqc-standards-have-been-finalized 2. SP 800-208 (stateful HBS): the stateful hash-based \- quantakrypto, https://quantakrypto.com/standards/sp-800-208-stateful-hash-signatures 3. Hey, That's My Model\! Introducing Chain & Hash, An LLM Fingerprinting Technique, https://www.microsoft.com/en-us/research/publication/hey-thats-my-model-introducing-chain-hash-an-llm-fingerprinting-technique/ 4. Putting the 'I' in CIA for AI Models: A Framework for Model Integrity \- Attacking AI and ML, https://cyberaiguy.com/putting-the-i-in-cia-for-ai-models-a-framework-for-model-integrity 5. AMD SEV-SNP: A Confidential Computing Primer \- arXiv, https://arxiv.org/html/2608.04039v1 6. AMD Secure Encrypted Virtualization (SEV), https://www.amd.com/en/developer/sev.html 7. W3C Decentralized Identifiers (DIDs) Specification \- Didit.me, https://didit.me/blog/w3c-decentralized-identifiers-dids-specification/ 8. W3C pushes DIDs v1.1 to implementations \- and your ad stack may feel it \- PPC Land, https://ppc.land/w3c-pushes-dids-v1-1-to-implementations-and-your-ad-stack-may-feel-it/ 9. SCITT: Supply Chain Integrity, Transparency and Trust \- Conserver.io, https://www.conserver.io/deep-dives/scitt-supply-chain-integrity-transparency-and-trust 10. draft-ietf-scitt-architecture-22, https://datatracker.ietf.org/doc/html/draft-ietf-scitt-architecture-22 11. draft-birkholz-scitt-architecture-02 \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-birkholz-scitt-architecture-02 12. RFC 9942 \- CBOR Object Signing and Encryption (COSE) Receipts \- IETF Datatracker, https://datatracker.ietf.org/doc/rfc9942/ 13. AMD SEV-SNP \- GitHub, https://github.com/ufcg-lsd/spire-amd-sev-snp-node-attestor/blob/main/docs/amd-sev-snp.md 14. AMD SEV-SNP attestation | Contrast, https://docs.edgeless.systems/contrast/1.9/architecture/snp 15. CoRIM profile for AMD SEV-SNP attestation report \- IETF, https://www.ietf.org/archive/id/draft-deeglaze-amd-sev-snp-corim-profile-01.html 16. SPIFFE \- API Evangelist \- Standards, https://standards.apievangelist.com/store/spiffe/ 17. AgentLair Now Issues Verifiable Agent Receipts via SCITT, https://agentlair.dev/blog/scitt-phase-2-receipts/ 18. RFC 9591 \- The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures \- IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc9591 19. nillion, https://nillion.com/news/improving-threshold-ecdsa-and-its-applications-to-ai-agents/ 20. cggmp21/README.md at cggmp24/m \- GitHub, https://github.com/LFDT-Lockness/cggmp21/blob/cggmp24/m/README.md 21. Linking Eternity: A Blockchain-Based Framework for Verifiable and Privacy-Preserving Digital Inheritance \- MDPI, https://www.mdpi.com/2079-9292/15/8/1642 22. Hash-based Signatures: State and Backup Management \- IETF, https://www.ietf.org/archive/id/draft-wiggers-hbs-state-02.html 23. SPIFFE — API Provider, Schemas \- APIs.io, https://apis.io/providers/spiffe/ 24. Microsoft's Signing Transparency Ledger concepts \- Azure Confidential Ledger, https://learn.microsoft.com/en-us/azure/confidential-ledger/microsoft-signing-transparency-concepts 25. SPIFFE Concepts, https://spiffe.io/docs/latest/spiffe/concepts/ 26. The Paper Will is Dead: Why Modern Wealth Requires Programmable Inheritance, https://www.cipherwill.com/blog/the-paper-will-is-dead-why-modern-wealth-requires-programmable-inheritance 27. Digital Wills & Cryptographic Controls \- Emergent Mind, https://www.emergentmind.com/topics/digital-wills-and-cryptographic-controls 28. tangle-network/cggmp-threshold-ecdsa: MPC protocols for threshold ECDSA \- GitHub, https://github.com/tangle-network/cggmp-threshold-ecdsa 29. JWT-SVID \- SPIFFE, https://spiffe.io/docs/latest/spiffe-specs/jwt-svid/ 30. IEEE 802.1AR-2018 \- IEEE Standards Association, https://standards.ieee.org/standard/802\_1AR-2018.html 31. UCC, 2022 Amendments to \- Uniform Law Commission, https://www.uniformlaws.org/committees/community-home?CommunityKey=1457c422-ddb7-40b0-8c76-39a1991651ac 32. 760 ILCS 3/ Illinois Trust Code., https://www.ilga.gov/legislation/ILCS/details?MajorTopic=\&Chapter=\&ActName=Illinois%20Trust%20Code.\&ActID=4001\&ChapterID=61\&ChapAct=760+ILCS+3%2F\&SeqStart=9700000\&SeqEnd=11300000 33. GitHub \- ZcashFoundation/frost: Rust implementation of FROST (Flexible Round-Optimised Schnorr Threshold signatures) by the Zcash Foundation, https://github.com/ZcashFoundation/frost 34. CGGMP21 In Rust At Last \- DFNS, https://dfns.co/article/cggmp21-in-rust-at-last 35. W3C invites implementations of Decentralized Identifier Resolution (DID Resolution) v1, https://www.w3.org/news/2026/w3c-invites-implementations-of-decentralized-identifier-resolution-did-resolution-v1/ 36. What is SPIFFE? Universal Workload Identity Framework Guide \- Palo Alto Networks, https://www.paloaltonetworks.com/cyberpedia/what-is-spiffe 37. Ensuring the Secure Use of the FROST Protocol \- Least Authority, https://leastauthority.com/blog/ensuring-the-secure-use-of-the-frost-protocol/ 38. FROST (Flexible Round-Optimized Schnorr Threshold Signatures) | Nostr Compass, https://nostrcompass.org/en/topics/frost/ 39. FROST Explained: Schnorr Threshold Signatures for Bitcoin | Lantr Engineering, https://lantr.io/blog/frost-schnorr-threshold-signatures-bitcoin/ 40. The bitcoin blockchain and ECDSA Nonce Reuse Private Key recovery attacks made easy., https://www.reddit.com/r/netsec/comments/7hknoo/the\_bitcoin\_blockchain\_and\_ecdsa\_nonce\_reuse/ 41. 802.1AR: Secure Device Identity |, https://1.ieee802.org/security/802-1ar/ 42. Standardized PUF-based Solution for Device eID \- Design And Reuse, https://www.design-reuse.com/article/61255-standardized-puf-based-solution-for-device-eid/ 43. An In-Depth Look At The NIST PQC Algorithms | DigiCert, https://www.digicert.com/blog/in-depth-look-at-the-nist-pqc-algorithms 44. Stateful Hash-Based Signature Schemes: SP 800-208 | CSRC \- NIST Computer Security Resource Center \- National Institute of Standards and Technology, https://csrc.nist.gov/news/2020/stateful-hash-based-signature-schemes-sp-800-208 45. SP 800-208, Recommendation for Stateful Hash-Based Signature Schemes | CSRC, https://csrc.nist.gov/pubs/sp/800/208/ipd 46. The SPIFFE Project \- GitHub, https://github.com/spiffe/spiffe 47. A Comparative Examination of Some Threshold ECDSA Protocols Used in Custody, https://blokzincir.bilgem.tubitak.gov.tr/a-comparative-examination-of-some-threshold-ecdsa-protocols-used-in-custody/ 48. SPIFFE Workload API, https://spiffe.io/docs/latest/spiffe-specs/spiffe\_workload\_api/ 49. Digital Citizenship. Your passport is not a document of… | by Boris (Bruce) Kriger \- Medium, https://medium.com/@krigerbruce/digital-citizenship-c6d21dade32f 50. Cryptocurrency Inheritance: The Complete Guide to Passing Down Digital Assets in 2026, https://willbox.me/blog/cryptocurrency-inheritance-complete-guide/ 51. ietf-scitt \- Supply Chain Integrity, Transparency, and Trust \- GitHub, https://github.com/ietf-scitt 52. SHSlib | Security IP Solutions \- Rambus, https://www.rambus.com/security/software-protocols/stateful-hash-based-signature-library/ 53. draft-ietf-scitt-architecture-10 \- An Architecture for Trustworthy and Transparent Digital Supply Chains \- IETF Datatracker, https://datatracker.ietf.org/doc/draft-ietf-scitt-architecture/10/ 54. The did:key Method v0.9 \- W3C Credentials Community Group, https://w3c-ccg.github.io/did-key-spec/ 55. Decentralized Identifiers (DIDs) v1.0 \- W3C, https://www.w3.org/TR/2019/WD-did-core-20191125/ 56. Digital Trustee Services Market Research Report 2034 \- Dataintelo, https://dataintelo.com/report/digital-trustee-services-market

[image1]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAcAAAAcCAYAAACtQ6WLAAAAkElEQVR4XmNgGOQgCYh3A7EwugQHEG+FYhAbBeCVlAHiJ0DciizIA8SSQBwKxL+BOAKIxYGYFSQZD8SzgPg+EP8E4qVAPAmIlUGSIEC6fTDgAsS/oDQGqALi50CshC4Bs28PEHMzQFzZxQCxikEEiK8yIOwLAuICIGYEcUBEIxDfAeKVUDbYj8hAAIpHATIAAP3zGM9f3v8PAAAAAElFTkSuQmCC>

[image2]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAwAAAAbCAYAAABIpm7EAAAA10lEQVR4Xu3RrQ9BURjH8bNhY/MS2EwQaDKaYmMjKJIiois2CknX/AMUTVA0RRU0xaYKApspvufec66zO0Ui+G2f3Z3nuffc8yLEP7+UMKpIqrEPOdQQ1y/pBDHFCCc0sUQbA1xQct4mFXSQxRVrRFQvgSN6amylhQzqeKBo9GT9jK5RczLBHjGj1sAdBaPm5KMPQthgAa+qyeccW/Hak5N3a00J+9SGCGCMqG7qDZu/lndwQx5l9I2eNctOGDOQNA5YYSZcy/IL+wLdkTcuD8Hjbvzz3TwBLFQieXz1O1wAAAAASUVORK5CYII=>

[image3]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAADUAAAAaCAYAAAAXHBSTAAADNElEQVR4Xu2XS6hNURjHP6EISUREHjHwKOQReSaJAUkGRAbkMVEKiYkTGUiESEnJAImBCQpFMRBGyqOQSIRQBgYU/j9rr+7aa+99zj73niOD86tf+9y1zl17Pb71rXXMWjSdMfJoIp//G3rKbnFhCSbKLbKznCHfyJlBfXvbzdBXLpDL5WhzL6zGBHla9o4rSrBDvpQDZBd5SZ4K6ocmZTzrppOcLe/La3JV4nX5XE5p+2qKwfKWHBtXlKSfnGru/azIFXNhGDJLXrY6J62r3C9fWbbz1J2UX82FSggdOSwrUXl7mWRu1fLec8zcqpaCTp+QX8zNWB6E4GdzDfMCzzj5LHl2FFbhnJweVyRQ/lQOjyvy2CR/Jc8i+sgH8rG5cPEwc4RLRzcyAzpgbvLYV6PS1X/xfWBLVGWkfGduBtioRfgGX8uBSZmP/13+SwEkFjIY4cRnVneYXGrZxEOk7Da3ErRNtKwP6kNIIGctHS0ZKvK33BeVx4yQ7y09KJ78vdh/KWCz3COfmHvHcblXrpEv5EFr69g6c30IXZbUxRAZd2SvuMJD/r9tLvTmp6syUM/3wgZZhQ+WPlOAFT8i+5trnwQT7tUzSTnvrxcmMJzYDH6mSQCERDVIscxgJShjUByUPEMmy5XmUv1bc1nVr4oP2ZuyR1JWDwyKiCFycvGDqjpyMcTcOfXJ0mdR0aA8rO6P5OkhczHQWuFeBIP6JsfHFR6yGNms2qCY4Z3mVmlrVFdrUCSQeFZXyO9WnLZrUTP8SJ3n5U/L7gsPe4E9weFLlgqhs2TORVE55IWZf989cyl8rZyT1JWFdO6vVIVwctNp7m1xp+fJj/KQ7B7VgV/pjXGFte2nMMx8uLOCJBHSc13XHnP/W+pc5FpEmuXO5+973P0emRtY0ZlAOZMR39OA8GKy5gZlTBo3hofyhrmEUg/+slv6qsRhSAbkVk7cDrLiwYSwR5gMDucQ2qMsboO/+QVQc6ZzIMlwSWjvfiwNHbwrF8YVTWC1vGDZbdIUlsiLlr/vGgWTd9WKL9wNh5DanhiHWyOgzYq5I6UZ7RdCSGyT0+KKBsAv8A32jwfUokULsz9P2o/eZ46UgAAAAABJRU5ErkJggg==>

[image4]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACcAAAAXCAYAAACI2VaYAAACtklEQVR4Xu2WTYiOURTHj1CEJDL5KqbZiAUxonwliQVJFqQsbNhY+ZjM6h2ysCBESko2LNiiUKZIE1bKRyGRCGFnQeH/n3PPO+c5z4d33nmVhX/9ep733Kd7zz33nHNfkf/6dzQWjIrGBjQSjI/GKk0Ea8BmMBsMzw7nNA+cl0EukkTnjoNNccBrGFgO7oPrYFviBngOOgc+zWg6uA3mxIFBiMG4BhbFAYreHwGvJO8Ex86Cr2B+GOOGuOtasDejtaKBYHrUxcXPgC9S4rno0X4Gp0QdMs0Fz9JzqGJK3ANbvHEX+JmeZZoAHoDHYJKzd4Gr0lwhFOkwuGI/OsA78BS0mbFA5txrMCXZ6BAd67aPnFhAS8GC9M5ozwQbpbrA1omu0a8a+CXqcZXawXvJOscnf6+3j5x2g4Pgiegap8EhsB28AEclmx4mbuYtX5h4vaJHutp9UCSO87s7YFyycaIPohHy4gmcAJNF52ch+Vy+kOyZxE+yDddfmOgMdZVOika45mx07k16ei0EW0VbDKPALmBRslS4BcYkm1fOOX9URZoh2uc+SbaXlTlnYrS/p6dplqjDZWlUd45Vx+qrco47PiAatT1h7E/OsVCYp8xXE9vEN7DE2bzqzo0Al8APyeeNibnCnGETZj/04qKsdFZYVNHx2Xp9oj1tB1iRxkw2Z7/Y8bk478W4+CrwERwDo8MYZZHfGQdkIN/88VlUGFEWyznJ38W8nV5GA8ubd6rdp7xbH4k6WFTyFO3cFIslisfGTa90Nm7+IngIbooWThTX7o1GNkVWLP+FsG9NlXKnvJhD3BSbtBfnoy3Owd+85ItuFDv2WrA3LS50V/TSHqo6RPORz5ZpA7gsxXnZqBjRHrA/vbdMnGxfotmJl4le+LFAWiIm+16wOA40oGmiVf1XHGu5fgMsI3yoKbfPdAAAAABJRU5ErkJggg==>

[image5]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA4AAAAWCAYAAADwza0nAAAA10lEQVR4XmNgGHZAEoirgFgAXQIfYATiZiB+AsQyaHJ4gTEQf4ViEJsowAnEi4H4ERD/BmIbVGncIAiIu4G4Aoj/A7EvqjR2IAbEa4FYFojLGSAao1FU4AClQBwDZYNsAmkEGYAXaDNA/MYD5cM0tsJVYAGuQPyXAaIQHW8FYg6EUgTgB+LlQKyCJg5KAA+B+AADwhUooAiI09EFGRAa7wKxOLIEKHWA4ugCEMshS0AByCXHGSCaQYaAgS0Qv2dA+OM5EGvBJIGgD4h/IcmD2HOR5EcB1QAAcDwqguzpHnIAAAAASUVORK5CYII=>

[image6]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA8AAAAXCAYAAADUUxW8AAABCElEQVR4XmNgGAVWQPwIiP8j4S9A/AzK/gvEW4FYDaYBG5gExN+A2BRNXBWI7wLxdSCWQZMDAx4gPgDEV4FYBFUKDBYyQFzhiy4BAkpA/ByI5wMxI5oczOCfQGyJKgUBfgwQk9PRJYAgnAHi7ylAzIImBwatDBCTPYFYEorlgbgeiF8CcSQQM8NVIwGYs14zQJw9C4rnMkDCoAWI+WCK0QE+/yowQEL6HBCLoUpBAD7/ggAspEFewgC44hcEOIF4BxD/A2IXNDmC8WvLAAnIXQwQtShAE4jfAvFSBlT/gkIW5Mz3QHyFARLycAAy8SEDIi2D4vEJAySNg+g/QPwAiHMZIE4fBQMCADRiPGc37SMlAAAAAElFTkSuQmCC>

[image7]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA4AAAAXCAYAAAA7kX6CAAABCklEQVR4Xu3TMUsCYRzH8X+IUChEBFJDJNaSvQNBCHFwFHJ3bdXJQqKlsaGpRULdfAESOIWCDr4DnYKoXcLBoPw+3j3d48WdN4s/+MA9//89dzzPcyeyNoniAgWcIWTXI/oGd5IY4AstlNFEB+d4cW61EkYVM1Sws9yWNCZ4N4tq0hO+cWk2jGyjbfvLFX5xjS2z4UoDN3pwig+McaSLHqkhqwd3Yr3tXhd8sivWshZb/oofMZ4UJId4wycSrp5v9ERFXftFbWBKD/YwlNUT9/GMmFl8EGuNObNoRB2P+nr+ne8xRujiwNVTX88tSuJxvnH0MUUdRTyih4x4TNJRzTjythNx/ohNgmYOKRkpeb4CH/AAAAAASUVORK5CYII=>