Back to selected work
Independent engineering project · Signal

Engineering backend correctness for decisions under uncertainty.

Signal is a reusable, protocol-governed decision-processing platform for events, evidence, assessment, decisions, learning, memory, replay, and audit. It makes dangerous operations explicit and inspectable without presenting the project as a client result.

The problem

When a timeout does not tell you whether the operation happened.

State-changing systems must distinguish a new operation from a retry, a duplicate event, a conflicting identifier, and a replayed request. Without explicit records, a caller may not know whether to retry, reconcile, or stop.

Signal’s repository describes a model where Queries, Mutations, and Events have stable names, schemas, idempotency metadata, replay information, subscriber dedupe, and audit evidence. Those are architectural mechanisms to inspect—not a blanket claim that every distributed failure is solved.

Architecture

Protocol first, execution explicit, evidence visible.

The public README identifies three kernel packages: @signal/protocol for shared contracts, @signal/runtime for dispatch and execution mechanics, and @signal/ports for dependency-inversion boundaries.

Idempotency as a contract

The reference proof is documented to retry payment.capture.v1, then force a conflicting reuse of its idempotency key.

Replay-aware operations

Replay metadata and subscriber dedupe are named behaviors in the documented runtime model, while delivery guarantees remain bounded.

Auditable evidence

The reference proof describes redacted audit and outbox evidence, making accepted and recorded behavior reviewable.

Domain-agnostic kernel

Decision packages sit outside the kernel, so runtime mechanics and domain intelligence remain separate concerns.

Reference walkthrough

A payment capture proof, as documented by the project.

The repository instructs developers to run pnpm proof:reference. The sequence below reflects the README’s stated proof scope; it is not presented as an execution performed during this portfolio build.

  1. 01

    Submit payment.capture.v1 with an idempotency key.

  2. 02

    Retry the same operation and observe replay handling.

  3. 03

    Force conflicting reuse of the operation identifier.

  4. 04

    Inspect redacted audit and outbox evidence.

  5. 05

    Check subscriber dedupe and run certification.

Evidence and limits

What the public artifact supports.

Signal evidence table
BehaviorSupporting sourceStatusLimitation
Stable operation contractsREADME: protocol, runtime, and ports packagesDocumentedThis page does not independently certify every contract.
Duplicate mutation handlingREADME reference proof: payment.capture.v1 with the same idempotency keyDocumentedExecution was not run in this portfolio build.
Conflict detectionREADME reference proof: forced idempotency conflictDocumentedThe exact response is not reproduced here.
Audit and outbox evidenceREADME reference proof: redacted audit and outbox evidenceDocumentedRetention and storage guarantees need deeper source review.
Subscriber deduplicationREADME reference proof: subscriber dedupe checkDocumentedExternal delivery guarantees remain outside this artifact.

This case study does not claim exactly-once external execution, tamper-proof audit records, complete replay prevention, or production adoption. Those properties depend on persistence, transaction boundaries, external side effects, retention, and deployment assumptions that require deeper inspection than the public README alone provides.