Threat Model and Trust Boundaries

Security starts with a practical threat model. In our case, we assume account takeover attempts, coercive social engineering, insider misuse, integration drift, and delayed institutional response after a verified death event. We also assume that users can hold assets across jurisdictions where legal and technical controls are inconsistent. Aftera therefore treats every transition as adversarial until identity, context, and policy checks are fully satisfied. The first design principle is that no single actor can produce irreversible outcomes alone, including Aftera itself.

The second principle is segmented authority. User identity, platform custody, and state-verifiable triggers are separated so that each domain contributes only part of the authority chain. This separation is reflected in both cryptography and runtime policy. Even if an attacker gains application access, they cannot produce lawful transfer commands without additional trust elements. Even if a state signal is unavailable, the system does not guess. Execution remains blocked until explicit confidence thresholds are met and recorded.

The third principle is operational proof. Every command in the execution path emits evidence with deterministic hashes, timestamps, and actor metadata. This evidence model is not decorative observability; it is legal infrastructure. Heirs, institutions, and counsel must be able to verify what happened, when it happened, and why it was authorized. The evidence stream is append-only and designed to remain machine-verifiable independent of any single UI representation.

Finally, we design for graceful failure. If any trust precondition is missing, the system fails closed while preserving continuity for non-destructive actions. Users can still inspect vault state, update planning preferences, or run living audits. But transfer and delete operations remain blocked until the required shard state, policy state, and assurance state converge. This gives users strong guarantees that accidental execution is structurally difficult, not merely discouraged by copy or warnings.

AES-256-GCM Envelope and Data Lifecycle

Aftera uses AES-256-GCM for data-at-rest envelopes because it provides confidentiality and authenticated integrity in one primitive. Each object receives an independent data encryption key with unique nonce requirements. Envelope keys are generated under strict entropy constraints and never reused for different payloads. Ciphertext, nonce, and authentication tag are stored together as immutable object records. Any tampering produces authentication failure at read time, preventing partial corruption from masquerading as successful decryption.

The system separates object encryption from key custody. Object keys are wrapped using the active policy and recoverable only through approved paths. Exact reconstruction controls depend on deployment configuration, account verification, recipient approvals, and the evidence required for the workflow.

Data lifecycle controls are explicit: ingest, classify, encrypt, retain, disclose, erase. At ingest, metadata is minimized and tagged by sensitivity class. At classification, each object is bound to living and legacy policy outcomes, including disclosure scope, delete-on-death flags, and retention windows for evidence. At disclosure, the response engine enforces claims-based scoping so heirs receive only the authorized subset. At erase, secure wipe routines are applied for privacy-at-death categories before heir channels unlock.

Operationally, this model reduces blast radius. A compromise of one storage segment does not grant plaintext access to unrelated objects because keys are independently wrapped. A compromised session token does not grant mass export rights because disclosure checks run per request with policy gates. A compromised integration endpoint does not override lifecycle status because policy state is authored under signed instructions. Encryption is therefore not an isolated feature; it is one layer in a coordinated chain of custody and policy enforcement.

Zero-Knowledge Architecture and MPC Discipline

Zero-knowledge in Aftera means the platform is intentionally prevented from holding sufficient information to unilaterally unlock user authority. We implement this through shard separation and constrained reconstruction semantics. The user shard remains tied to user-controlled context. The platform shard remains in managed custody. The oracle shard remains inaccessible unless finality protocol criteria are met. Each shard domain has separate audit surfaces and separate recovery pathways, reducing correlated failure risk.

Multi-Party Computation principles are applied to practical custody operations even where full MPC is not the most efficient primitive. The core objective is the same: no single participant can complete the critical operation alone. Reconstruction ceremonies occur in hardened runtime boundaries and are short-lived by design. Key material in plaintext form exists only in memory for the minimal duration needed to perform the signed operation. Persistent storage receives ciphertext or hashed evidence artifacts, never operational plaintext secrets.

Runtime discipline is enforced by command middleware. High-risk commands such as transfer and delete require validated shard state before execution planning can begin. If the oracle shard state is absent or stale, the command is rejected without partial side effects. If identity assurance falls below threshold, the command is rejected with a corrective path. If policy references are missing, the command is rejected and logged as policy-incomplete. These rejections are considered successful security outcomes, not errors to suppress.

From a governance perspective, zero-knowledge claims are only meaningful when independently testable. Aftera therefore documents shard transitions, custody events, and reconstruction attempts in audit channels suitable for external review. Partners and regulators can inspect whether the platform behaved as declared. This turns trust from a marketing adjective into an engineering output. The architecture is designed to let external parties verify that we could not have acted alone, even if we wanted to.

• No unilateral full-key custody by platform operators.
• Per-command reconstruction checks under assurance policy.
• Memory-only sensitive operations with immediate key disposal.
• Independent auditability for custody and command decisions.

Oracle Trigger Protocol and Execution Safety

The oracle-trigger protocol is the bridge between legal finality and technical execution. It combines state-registry observations, heartbeat liveness checks, and circle-of-trust escalation before any irreversible workflow starts. The protocol does not treat one signal as complete truth. Instead, it computes confidence from multiple sources and requires deterministic thresholds for mode transitions. This approach reduces false positives and ensures that automated execution remains bounded by evidence, not heuristics.

Once finality confidence reaches threshold, the protocol releases the oracle custody path required for post-mortem reconstruction. Release is policy-scoped and time-bounded. It does not grant broad platform powers; it grants only the authority necessary to execute the approved manifest sequence. Each manifest action is then evaluated by command guardrails before dispatch. If a downstream dependency fails, the action is retried or escalated according to policy, while preserving prior evidence and preventing silent drift.

Execution safety relies on priority ordering. Estate-bleed prevention occurs first to stop recurring liabilities. Institutional notifications and claim initiations follow with signed evidence packages. Transfer actions execute next based on manifest dependencies and jurisdictional rules. Memorialization and privacy workflows execute last, because they often depend on earlier disclosures and claim outcomes. This ordering ensures financial harm is reduced quickly while legal documentation remains coherent for heirs and counterparties.

The end state is measurable. Success means that heirs can review a complete chain of events without reconstructing hidden context from email threads or fragmented portals. Success also means that non-executed actions are explicit, justified, and queued with next steps. Aftera treats incomplete execution as a transparent operational state rather than an opaque failure. This is crucial for trust: users and heirs need clarity even when institutions respond slowly or external systems degrade under load.