Dead Contract Queue: Cascading Multi-Layer Contract Execution

March 2, 2026 · architecturecontractsexecution-engine

I will hopefully be open sourcing this soon. This little technical write up on a system I designed. I wrote system in golang.

I built something I couldn’t find anywhere else.

Not a framework. Not a pattern I borrowed and renamed. Not another flavor of “clean architecture.” This came from repeatedly running into the same problem: logic scattered everywhere, validation leaking across boundaries, and state transitions that felt more like guesswork than engineering. I wanted something deterministic. Something that made advancement impossible without proof. Something that enforced order without becoming rigid.

The Dead Contract Queue grew out of that frustration. It’s layered on purpose. It uses facets because steps deserve ownership. It produces receipts because nothing should move forward without evidence. And it cascades because real systems aren’t linear — they adapt. This isn’t about abstraction for abstraction’s sake. It’s about clarity under pressure. Execution with boundaries. And building systems that don’t rot the moment they scale.

I use it anywhere a process has real steps and real consequences — onboarding flows, admin creation, hardware provisioning, verification pipelines, even weird edge-case experiments. Think about a 100-person test: 30% get a slightly different version, 10% of women get additional contextual questions, 25 people are doing it on kiosks, 5 are doing it on a PS1 for fun, and a few diehards are chiseling answers into a stone tablet. Same contract. Different fulfillment paths. Each step owns its logic, each completion returns a receipt, and nothing advances unless it earns it. No spaghetti. No mystery transitions. Just structured progression.

It could be used for anything that requires ordered trust — signups, compliance flows, identity verification, staged deployments, multi-surface UX, or adaptive onboarding where conditions shift mid-stream. The fun part is that it doesn’t care whether the interface is an iPad, a CLI, a Discord OAuth callback, or a stone tablet in a cave somewhere. The contract stays stable. The facets adapt. The system stays clean. And you get to scale complexity without losing your mind.

Dead Contract Queue (DCQ)

The Dead Contract Queue is a contract-driven execution architecture built around:

  • Multi-step facet execution
  • Receipt-gated advancement
  • Layered fulfillment boundaries
  • Cascading conditional paths
  • Infrastructure abstraction via adapters
  • Terminal state preservation

Contract Definition

A Contract Definition specifies:

  • Required invariant structure
  • Ordered and conditional fulfillment layers
  • Valid state transitions
  • Mandatory receipt production per facet
  • Terminal state conditions

In a single-binary system:

  • Contracts are issued centrally
  • Definitions are static
  • Versioning is unnecessary unless persisted across releases

Contracts cannot be arbitrarily created outside the issuer boundary.

Contract Instance

A Contract Instance represents a live execution.

It contains:

  • ID
  • Type
  • Current Layer
  • Current Facet
  • State
  • Context
  • Receipt Log
  • CreatedAt
  • UpdatedAt
  • TerminalState (if reached)

State progression is deterministic and receipt-driven.

Facets

A Facet is a deterministic execution unit responsible for:

  • Validating required inputs for its step
  • Enforcing contextual requirements
  • Producing a receipt
  • Allowing or denying advancement

If validation fails:

  • A failure receipt is generated
  • The contract remains in the current facet
  • Advancement is blocked

Facets do not:

  • Access storage directly
  • Alter contract invariants
  • Skip receipt production

Receipt Model

Receipts are append-only execution records.

A receipt contains:

  • ContractID
  • LayerID
  • FacetID
  • Status (Success or Failure)
  • NormalizedInput
  • Output
  • Timestamp
  • ContextMetadata

No advancement occurs without a valid success receipt.

Layered Fulfillment Model

Execution is divided into demarcated fulfillment layers.

Example: Administrative Signup

Layer 1: Identity
Layer 2: Credential
Layer 3: Verification
Layer 4: Finalization

Each layer:

  • Contains one or more facets
  • Owns a clearly defined responsibility
  • Cannot leak validation across layers
  • May contain conditional branching

Identity logic remains separate from credentials.
Credential logic remains separate from verification.
Verification logic remains separate from finalization.

Cascading Conditional Execution

Contracts support conditional fulfillment paths within a layer.

Example facets within the Identity layer:

  • DiscordOAuthFacet
  • PasswordFacet
  • SSOFacet

Rules:

  • If Discord succeeds → PasswordFacet is bypassed
  • If Discord fails → PasswordFacet activates
  • Only one valid success receipt path is required to satisfy the layer

This creates cascading execution flows without altering contract invariants.

Context-Aware Field Enforcement

Field requirements are facet-scoped and context-driven.

Examples:

  • If gender equals female → FemaleDataFacet activates
  • If biometric device present → BiometricFacet required
  • If device supports camera → PhotoCaptureFacet activates

Validation is enforced only at the relevant facet boundary.

There is no global scattered sanitization layer.

Callbacks and Re-Entry

Asynchronous steps re-enter the contract through defined facet boundaries.

Examples:

  • OAuth redirect return
  • Biometric capture completion
  • External verification callback

Callbacks:

  • Resume execution at the correct facet
  • Must produce a receipt
  • Cannot bypass validation rules

Dead Contract Queue (DCQ)

A contract instance transitions to the Dead Contract Queue when it reaches a terminal state:

  • Completed
  • Failed
  • Expired

The DCQ preserves:

  • Entire receipt chain
  • Fulfillment path taken
  • Final state
  • Execution metadata

The DCQ is append-only.

Infrastructure Adapters

Infrastructure is abstracted behind interfaces.

Possible adapter implementations:

  • InMemoryStore
  • FileStore
  • DatabaseStore
  • MessageQueueStore

Core contract logic does not depend on infrastructure.

Adapters transform representation, not contract invariants.

Architectural Guarantees

The Dead Contract Queue architecture ensures:

  • Deterministic state progression
  • Receipt-gated advancement
  • Layer-bound validation
  • Context-driven facet activation
  • Centralized contract issuance
  • Infrastructure independence
  • Terminal state preservation
  • Elimination of scattered validation logic

Summary

Contracts define outcomes.
Facets enforce steps.
Receipts gate progression.
Layers demarcate responsibility.
Terminal states are preserved.

The contract fields are finite, but the delivery and incoming patterns are not. The structure is controlled, predictable, bounded — but the ways data arrives, devices interact, or users fulfill a step can vary endlessly. That’s the point. The contract defines what must be true. The facets and adapters handle how it becomes true. Structure stays tight. Interfaces stay flexible.

Nothing advances without proof.

← All posts