The Déjà system, documented for review.

Déjà persists a small number of entities. The data model is deliberately narrow — most artifacts of the attribution pipeline (raw diffs, error payloads, intermediate computation) are processed in-memory and discarded after extraction.

Key invariants. The data model enforces several invariants below the application layer — they cannot be violated even by a privileged operator:

• All tables are vault-scoped. Cross-tenant queries are forbidden at the storage layer via row-level security policies.
• The audit_log table is append-only. UPDATE and DELETE permissions are revoked at the role level; the schema enforces this via triggers.
• Every receipt's signature field is computed at issuance and never mutated. Modifying any signed field invalidates the signature and is detectable offline by the verifier CLI.
• The upg_nodes.schema_delta field is the only persisted artifact of a PR diff. The raw diff content is discarded after extraction.

The normalization engine transforms raw error signals into stable, comparable artifacts. Without normalization, a refactor that moves a function or renames a parameter would change the fingerprint of every error originating from that function — destroying the join between error signals and UPG nodes.

Normalization happens in three phases, each producing a canonical artifact:

The fingerprint is the SHA-256 of the canonical concatenation of these three artifacts:

// Fingerprint computation. Stable across refactors and line-number drift.

export class FingerprintEngine {
  static hash(signal: { errorType: string; messageTemplate: string; stackFrames: string[] }): Fingerprint {
    const canonical = [
      signal.errorType,                          // canonical taxonomy
      signal.messageTemplate,                    // variables stripped
      signal.stackFrames.join(' :: '),           // (fn_name, file_path) pairs
    ].join(' || ');

    return {
      algo: 'SHA-256',
      value: sha256(canonical),                  // hex-encoded
      canonical_form_version: 'v1',             // bumped on taxonomy changes
    };
  }
}

Two errors that look textually different but reduce to the same canonical form share a fingerprint. This is the key property that makes attribution work across refactor cycles.

Before any receipt is issued, the validation orchestrator runs five trust gates sequentially. The composition is strict AND: a single gate failure halts attribution and logs the failure reason to the audit ledger. No receipt is issued. No customer-facing alert fires.

The full gate composition logic and code path is documented in The Engine, §06 Trust Gates.

An incident moves through seven terminal states. Five of them produce a receipt (R0 ingestion always fires; R1-class receipts fire conditionally). One produces an audit log entry only.

Timing characteristics are aspirational targets governed by service-level objectives, not hard guarantees. Production benchmarks accumulate in §08 as deployments mature. Current targets:

• Webhook ingest → fingerprint: < 30 seconds (target)
• Fingerprint → attribution: < 10 seconds (target)
• Attribution → delivery: < 5 seconds (target)

Integrations are categorized by readiness: Live (production-validated), Beta (functional, undergoing validation), and Q3–Q4 2026 (specification-complete, build pending). Authentication mode and webhook payload requirements are documented per provider in the standalone Docs page.

The 13 first-party integrations cover the bulk of customer environments. Indirect coverage of an additional 700+ tools is achieved via aggregator hubs — primarily PagerDuty's event source library and Splunk On-Call's webhook intake. See the Integrations Directory for the full list.

• →Top-level deja.yaml schema — vault, integrations, channels, retention, and policy blocks
• →Vault provisioning — region selection, signing key rotation, isolation policy
• →Retention policy — per-receipt-class retention horizons and configurable overrides
• →Channel routing — which receipt classes deliver to which Slack / PagerDuty / email destinations
• →Webhook authentication — per-provider HMAC and shared-secret configuration
• →Validation rules — schema validation errors, deprecation warnings, and migration paths

• →Webhook ingestion latency — p50, p95, p99 per provider, per region
• →Attribution latency — signal arrival to receipt issuance, end-to-end
• →Throughput characteristics — sustained webhook rate per vault, burst tolerance
• →UPG query performance — graph traversal cost as PR volume grows
• →Storage growth — receipt and audit-log durable footprint per active vault
• →Scaling boundaries — vault-count and receipt-rate thresholds at which deployment topology must change

• →Webhook ingestion failures — provider downtime, signature verification failures, replay handling
• →AST parsing failures — malformed diffs, unsupported syntax, language-specific edge cases
• →Trust gate failures — covered conceptually in §04; this section will cover operational diagnosis
• →Storage layer failures — database unavailability, signature key rotation failures
• →Cross-region replication — eventual-consistency boundaries for multi-region deployments
• →Recovery procedures — operator runbook for each failure class

• →Tenant isolation boundary — cryptographic and database-level separation between vaults
• →Webhook authentication and replay — HMAC verification, nonce handling, clock-skew tolerance
• →Receipt forgery prevention — signature scheme, key rotation, fields-signed canonicalization
• →Insider threat (Déjà operators) — append-only audit log, signed-fields immutability
• →Supply-chain exposure — dependency review, build provenance, deployment integrity
• →Compliance exposure scenarios — what an attacker would need to do to invalidate a regulator-facing receipt

This section is a brief reference. The full security architecture lives on the Security page, including the zero-retention diagram, subprocessor table, and data-handling commitments.

Déjà's spec evolution policy is conservative by design. Receipts may be verified months or years after issuance, often by auditors using a verifier CLI version different from the one that produced them. Backward compatibility is treated as a regulatory commitment, not an engineering preference.

• →Webhook authentication failures — HMAC mismatches, signature verification, clock skew
• →Trust gate failure diagnosis — reading the audit ledger, interpreting failure codes
• →Receipt verification failures — verifier CLI return codes and remediation steps
• →Integration-specific issues — provider-by-provider known issues and workarounds
• →UPG node misses — diagnosing why a known PR is not appearing as an attribution candidate
• →Channel delivery failures — Slack token expiry, PagerDuty rate limiting, email bounces

• →Déjà is not a logging platform. It does not store, search, or retain log content.
• →Déjà is not an APM. It does not collect spans, traces, or runtime metrics.
• →Déjà is not an alerting tool. It produces receipts and delivers them to channels, but does not page on-call.
• →Déjà does not store source code. It processes webhook diffs in-memory and discards them after schema extraction.
• →Déjà does not do anomaly detection or pattern learning. The CCS is computed from named factors, not learned weights.
• →Déjà is not a substitute for incident management. It augments existing tools (PagerDuty, FireHydrant, incident.io); it does not replace them.

• →KeyError — Field-access failure; primary signal for W1 schema overlap.
• →TypeError — Type mismatch; strong signal for W4 error type match.
• →SchemaValidationError — Explicit schema validator failure; strongest W4 signal.
• →NullPointerException — Null dereference; W4-eligible.
• →UndefinedReferenceError — Symbol not found in scope; W4-eligible.
• →SerializationError — Encode/decode failure across schema boundary; W1 + W4 eligible.

The full taxonomy is versioned with the DSR specification. New error types added in MINOR versions are backward-compatible.