Patent summary.
Built for Heads of Risk, CISOs, patent counsel, and audit-firm technologists at firms operating under SOC 2 Type II, ISO 27001, NYDFS Part 500, DORA, or SR 11-7 — the stakeholders most likely to cross-check Déjà's marketing claims against the USPTO filing record. Déjà's deterministic incident attribution engine, cryptographic receipt generation, and tamper-evident chain of custody are protected by a family of pending patent applications. This page is a product-facing summary of the filing scope — not the official filing record. The authoritative claim text lives in the USPTO record under the application numbers below. Receipts export as standard signed JSON and are verifiable offline using the open CLI by any audit firm — the verifier CLI is open-source and works with any firm (e.g., KPMG, Deloitte, EY, PwC, BDO, Grant Thornton, or independent); no Déjà account required. Cross-checking against the USPTO filings directly is recommended.
| Application | Scope | Filed | Status |
|---|---|---|---|
| 18/668,178 U.S. Non-Provisional · Parent | Integrated Real-Time Issue Reporting Parent application establishing priority chain — telemetry correlation primitives, communication-platform foundations | May 19, 2024 | Pending |
| 19/430,349 U.S. Non-Provisional · CIP of 18/668,178 | Deterministic Incident Resolution + Predictive Cross-Service Alerting Claims 1–24: file/rate/duration validation gates, regression detection via revert events, dual-lane ingestion, knowledge-graph indexing, cross-service preventative alerts | December 23, 2025 | Pending |
| CIP · March 2026 — application number pending assignment U.S. Non-Provisional · CIP of 19/430,349 | Tamper-Evident Chain of Custody Claims 25–31: cryptographic receipt generation pipeline, append-only hash-linked ledger, recurrence chain, human-readable receipt document for SOC 2 / ISO 27001 / chain-of-custody evidentiary standards | March 19, 2026 | Pending |
| SDE Provisional — application number pending assignment U.S. Provisional · 35 U.S.C. § 119(e) | Schema Deduction Engine + Upstream Producer Graph + CCS Asynchronous cross-service root cause attribution without distributed trace identifiers · Edge Parser embodiment for regulated deployments where source code cannot leave the network boundary | March 25, 2026 | Pending |
A computer-implemented method for forensic attribution.
A computer-implemented method for linking runtime telemetry signals to version control changes using deterministic matching gates. The system generates a Verified Artifact Signature from normalized evidence and correlates it with code-change events. Upon confirmation of a verified fix, the system initiates a cryptographic receipt-generation pipeline that serializes the resolution record into a canonical receipt object, computes a SHA-256 digest, applies a digital signature, and records the signed receipt artifact in an append-only ledger — establishing a tamper-evident chain of custody for compliance auditing and incident recurrence verification.
The method operates without reliance on probabilistic similarity, machine-learning inference, or runtime trace correlation. Determinism is the central technical claim. Each step in the pipeline produces a verifiable artifact; each artifact is independently auditable; each receipt is sealed at issuance and cannot be modified post-fact.
The problem space, and what existing approaches miss.
Distributed software systems generate substantial telemetry — error reports, log entries, performance traces — that is difficult to correlate with the specific code changes responsible for any given runtime fault. Existing approaches to this correlation fall into two categories, both of which are inadequate for compliance and audit contexts.
The invention addresses both inadequacies with a deterministic validation orchestrator that admits a candidate change only if it passes a fixed sequence of cryptographically-verifiable gates. A confirmed fix produces a signed, timestamped receipt artifact — an audit-grade record of "this change resolved this incident at this time."
Two pipelines. Validation, then signing.
The invention comprises two principal pipelines, depicted in the figures below. The validation orchestrator (Fig. 1A) determines whether a candidate code change qualifies as a verified fix. The cryptographic receipt-generation pipeline (Fig. 1B) seals a verified fix into a tamper-evident audit artifact.
The validation orchestrator implements a sequence of deterministic gates. Each gate is a binary check — pass or halt. A single gate failure terminates processing and produces no signed artifact. The full system implements five such gates (File, Rate, Infra, Feature Flag, Duration); the figure depicts three for clarity.
A method for confirming a fix only when a sequence of deterministic gates all pass. Eliminates probabilistic confidence in favor of binary pass/halt semantics.
When an auditor asks “how do you know this fix worked?” — the answer is a timestamped, evidence-backed gate sequence, not a recollection.
Establishes that no machine-learning model determines whether an incident is resolved. Every match is verified by a specific, deterministic gate, not a probabilistic runtime score.
No black-box model decides whether your incident was resolved. Every match traces to a specific file, commit, and error rate — defensible in audit or regulatory proceeding.
Detects PR reverts and regression patterns, applying a penalty to the confidence record. Quietly rolls back attribution rather than producing a false-positive audit entry.
Déjà won't credit a fix that was quietly rolled back — protecting the compliance record from false positives in an audit.
Surfaces a preventative alert when validated resolution patterns indicate that a service in the consumer graph would have crashed had the fix not been applied.
Teams earn credit for fixes in Service B because Service A already survived it. Audit-grade evidence of incidents that would have escalated.
The cryptographic receipt pipeline is the subject of the March 2026 Continuation-in-Part filing (Claims 25–31). Once a fix is verified by the validation orchestrator, the system serializes the resolution into a canonical receipt object, computes a SHA-256 digest, applies a digital signature using a tenant-scoped private key, and records the signed artifact in an append-only ledger from which no direct entry may be modified or deleted.
Edge Parser embodiment for regulated deployments.
The Schema Deduction Engine provisional (filed March 25, 2026; 35 U.S.C. § 119(e)) introduces a deployment embodiment specifically scoped to regulated environments where source code cannot leave the producer organization's network boundary. Under this embodiment, the AST analysis and PayloadMutation record generation are performed by an isolated Edge Parser agent deployed entirely within the customer's own infrastructure.
The Edge Parser is deployed as one of: a containerized process, a GitHub Actions workflow step, a GitLab Runner job, or a CI/CD pipeline plugin executing within the customer's own environment. Upon receipt of a pull_request.merged webhook event, the Edge Parser performs all source code parsing, payload mutation detection, and field identifier extraction locally. The agent then transmits to the centralized Upstream Producer Graph index only abstracted graph metadata — service identifier, field identifier, operation type, pull request identifier, and merge timestamp — digitally signed by the Edge Parser prior to transmission for integrity verification.
This embodiment is co-claimed within the SDE provisional rather than separately filed: the same independent claim covers both deployment models, ensuring patent coverage of source-code-confidential implementations is not severable from coverage of the standard deployment.
Six selected claims, summarized.
Plain-English summaries of six claims central to the patent family — three from the Schema Deduction Engine provisional (March 25, 2026) and three from the Tamper-Evident Chain of Custody CIP (March 19, 2026). These are paraphrases, not the verbatim claim text — the official claim language is in the USPTO filing record.
Asynchronous Cross-Service Root Cause Attribution
A computer-implemented method for asynchronous cross-service root cause attribution in a distributed microservice system, comprising: maintaining a pre-computed Upstream Producer Graph (UPG) index by subscribing to version control system webhook events and asynchronously analyzing source code changes to identify producer and consumer registration patterns for asynchronous messaging queues; updating directed graph edges in the UPG index within a target latency of two seconds from webhook receipt; receiving a production error signal from a subscriber service indicating a schema mutation error; extracting a Schema Error Tuple (SET) comprising at least a field identifier and receiving service identifier; querying the pre-computed UPG index to identify candidate producer services without performing a real-time version control API scan; computing a Causal Confidence Score (CCS) for each PayloadMutation record using a weighted multi-factor formula comprising at least a direct field match score, an AST mutation score, a semantic similarity score, and a temporal proximity score; and generating a cross-service incident attribution record for the highest-CCS candidate exceeding a configurable threshold — without requiring a distributed trace identifier propagated through network request headers.
Existing observability platforms cannot attribute schema-mutation errors across asynchronous queues because trace identifiers don't survive Kafka, RabbitMQ, SQS, or Pub/Sub. Déjà's pre-computed UPG architecture bridges that gap entirely — your audit firm sees signed attribution evidence even when the trace is gone.
No-Trace-ID Declaration as Evidence
The cross-service incident attribution record further comprising an explicit declaration that no distributed trace identifier was used in the root cause attribution, constituting machine-verifiable evidence of trace-independent deduction.
The receipt itself states, cryptographically, that no trace ID was relied upon. Your audit firm doesn't have to take this on faith — they verify it offline using dsr-verifier-cli. The declaration is a signed field, not a marketing claim.
Edge Parser Embodiment for regulated deployments.
The asynchronous source-code analysis and PayloadMutation record generation is performed by an isolated Edge Parser agent executing within a secure network boundary of the producer organization — deployed as a containerized process, a GitHub Actions workflow step, a GitLab Runner job, or a CI/CD pipeline plugin within the customer's own infrastructure. The Edge Parser transmits only abstracted graph metadata — service identifier, field identifier, operation type, pull request identifier, merge timestamp — to the centralized UPG index. No source code, code diff, file content, or repository data leaves the producer organization's network boundary. The abstracted metadata is digitally signed by the Edge Parser agent prior to transmission.
Banks, healthcare systems, and government agencies operating under NYDFS Part 500, DORA, SR 11-7, HIPAA, or FedRAMP cannot ship source code to a vendor. The Edge Parser is the architectural answer — Déjà's attribution engine works identically without any source-code egress. The same patent claim covers both the standard cloud-pull deployment and the source-code-confidential deployment.
Tamper-Evident Chain of Custody Record Generation
A computer-implemented method for generating a tamper-evident audit record for a validated software incident resolution, comprising: receiving a validated resolution record from any automated validation source that verifies a code change resolved an error signal; generating a canonical receipt object by serializing the validated resolution record into a deterministic byte representation; computing a cryptographic digest of the canonical receipt object to produce an incident receipt fingerprint; applying a digital signature to the incident receipt fingerprint using a private signing key to produce a signed receipt artifact; recording the signed receipt artifact in an append-only ledger such that no modification, deletion, or substitution of a prior entry is permitted after the entry is written; and associating the signed receipt artifact with the incident identifier such that subsequent retrieval of the incident identifier returns the signed receipt artifact as authoritative evidence of resolution.
Your audit receipt is cryptographically sealed the moment a fix is confirmed — not assembled by hand days before the auditor arrives. An independent party can verify its integrity without ever touching your systems.
System for Tamper-Evident Chain of Custody
A system for generating a tamper-evident chain of custody record for a validated software incident resolution, comprising: one or more processors and a non-transitory memory storing instructions that cause the system to receive a validated resolution record from any automated validation source that verifies a code change resolved an error signal; generate a canonical receipt object by serializing the validated resolution record into a deterministic byte representation; compute a cryptographic digest of the canonical receipt object to produce an incident receipt fingerprint; apply a digital signature to the incident receipt fingerprint using a private signing key to produce a signed receipt artifact; record the signed receipt artifact in an append-only ledger such that no prior entry may be modified, deleted, or substituted after being written; and associate the signed receipt artifact with the incident identifier such that subsequent retrieval of the incident identifier returns the signed receipt artifact as authoritative evidence of resolution.
No one — not an engineer under pressure, not an admin with access, not Déjà's own operators — can quietly revise a past resolution record. What was signed at attribution is permanently what your auditor, regulator, or insurer sees.
Human-Readable SOC 2 / ISO 27001 Receipt Document
Further comprising generating a human-readable receipt document from the signed receipt artifact, the human-readable receipt document including at least the incident identifier, the resolution artifact identifier, the validation timestamp, the incident receipt fingerprint, and a verification instruction sufficient to allow an independent party to confirm the cryptographic digest without access to the private signing key, wherein the human-readable receipt document is structured to satisfy at least one of SOC 2 Trust Services Criteria for Availability, ISO 27001 Annex A 5.24, or a chain of custody evidentiary standard applicable to digital artifacts.
Every received receipt automatically produces a document your SOC 2 Type II auditor can read and your ISO 27001 reviewer can file. Compliance prep that used to take days is done before you close the incident ticket.
The excerpts above are provided for technical review and product differentiation aligned with the current Déjà platform. For complete legal scope, refer to the official filing and executed customer agreements.
How the four applications relate.
The patent family spans four applications in a single priority chain. Each filing extends or specializes the protection in a distinct technical direction. The chain establishes Déjà's priority dates from May 2024 through March 2026.
What this page is, and isn't.
The "Deterministic Incident Resolution" system, including the tamper-evident chain of custody and cryptographic receipt-generation pipeline described herein, is represented as part of Déjà's current platform narrative. The patent family establishes priority through a chain originating with U.S. Application 18/668,178 filed May 19, 2024, and includes the December 23, 2025 CIP (19/430,349), the March 19, 2026 CIP, and the March 25, 2026 SDE provisional — all currently pending before the United States Patent and Trademark Office.
Patent claim breadth versus implementation specificity. The filed claims use standard claim-drafting language designed to read on the broadest reasonable interpretation. For example, "applying a digital signature using a private signing key" reads on any digital-signature scheme — including HMAC, ECDSA, Ed25519, and KMS-managed keys. The current production implementation comprises two distinct steps, both within the disclosed embodiments: (1) a SHA-256 canonical-payload digest computed via node:crypto (the fingerprint/hash step), and (2) an Ed25519 digital signature applied over that digest, also via node:crypto (the private-key signing step). "Applying a digital signature using a private signing key" in the filed claims reads on each step independently and on the combination — encompassing HMAC, ECDSA, Ed25519, and KMS-managed key arrangements. Both the broader filed scope and the specific production implementation are within the disclosed embodiments — see Security and The Engine for implementation detail.
Patent references and claim scope should be interpreted only through the official filing and counsel-reviewed legal documentation. This page is a product-facing summary intended for technical review, buyer evaluation, and working-group orientation. It does not replace formal legal documentation, does not constitute legal advice, and does not grant any license to the underlying claims.
For procurement, audit, or licensing inquiries, see the contact form's Security review or Press · partnership · working group paths. For technical deep-dives on the implemented system, see The Engine and the System Documentation.
Licensing, working group, or audit questions?
Selecting "Press · partnership · working group" or "Security review" on the contact form routes to the founding team. Patent licensing inquiries are evaluated case-by-case with priority given to working-group participants and Charter customers.