Skip to main content
DoneThat

AI Adoption GuideLegalDispute

Breach timeline reconstruction

Extracts obligations from the contract and maps them against actual events to produce a structured breach chronology.

Legal processRequestAssessDraftNegotiateApproveSignStoreDispute

By Don, DoneThat’s AI coach · updated

Overview

A breach timeline reconstruction turns scattered contract language and operational records into a dated chronology where every listed event can be traced to a specific obligation and a specific piece of evidence. The workflow does not decide whether a breach occurred. It structures what happened, when, and which contractual duties were implicated, so counsel can argue breach with a defensible factual spine rather than a narrative assembled from memory.

The starting point is always the contract corpus: master agreements, statements of work, amendments, order forms, and side letters. Obligation-bearing language is extracted and normalized into discrete duties with stable identifiers, each anchored to a clause span (document, section, and character or paragraph range). Parallel ingestion pulls event candidates from email, ticketing systems, project logs, invoices, delivery confirmations, status reports, and platform exports. The reconstruction engine aligns events to obligations by matching parties, subject matter, performance windows, and defined terms, then orders the result into a breach-oriented chronology.

What the chronology contains

Each row in the output is an event candidate linked to one or more obligations and one or more evidence sources. A complete entry includes:

  • Event date or date range, with timezone and ambiguity flags when sources disagree
  • Event description in neutral factual language, without legal conclusions
  • Obligation reference, including clause span and the normalized duty text
  • Evidence citation, pointing to the underlying record (message ID, ticket number, file hash, or export line reference)
  • Mapping confidence where the link is inferential rather than explicit

Events that cannot be tied to an extracted obligation are excluded from the primary chronology. They may appear in a separate "unmapped activity" appendix if the matter team opts in, but they do not populate breach rows. That constraint prevents the timeline from implying contractual breach where no duty has been identified.

Obligations that never receive a mapped event remain visible in an obligations ledger, not as silent gaps in the timeline. Empty breach chronologies are valid outputs when mapping fails: the system reports which obligations lacked evidentiary support and which events lacked contractual hooks, rather than fabricating connections.

Obligation extraction and span integrity

Obligation quality determines timeline quality. Extraction must preserve definitional cross-references, conditions precedent, carve-outs, and cure periods. A payment deadline buried in a fee schedule is not equivalent to a milestone in an SOW, even if both mention dates.

Clause spans are stored so reviewers can jump from any timeline entry back to the exact contractual language. When amendments supersede earlier terms, the reconstruction applies effective-date logic: obligations active on the event date govern the mapping. Conflicting versions trigger a conflict flag instead of silent resolution.

This work pairs naturally with ongoing obligation tracking, which maintains the live duty register across contract changes. Reconstruction consumes that register at a matter cut-off date so the chronology reflects obligations as they stood during the disputed period, not as later renegotiations might recast them.

Evidence alignment across platforms

Dispute and contract platforms rarely share a single schema. Reconstruction therefore treats exports as evidence objects with provenance metadata, not as authoritative truth.

Ironclad and similar contract lifecycle tools supply executed agreements, redline history, and obligation metadata that anchor clause spans. Relativity and Everlaw host review sets where communications, productions, and tagged issues provide event candidates and corroboration. Logikcull and comparable collection workflows contribute early-phase document sets whose hashes and load files become citation targets.

The mapper does not privilege one vendor's labels over another. A "responsive" tag in a review platform is evidence of human judgment at a point in time, not a substitute for obligation text. Similarly, a contract playbook field in Ironclad may suggest a duty category but cannot replace the signed clause span cited in the chronology.

Where the same fact appears in multiple systems, the reconstruction prefers the earliest authentic record and lists secondary sources as corroboration. Discrepancies (for example, a ticket marked complete while email threads show open defects) surface as explicit conflicts for counsel to resolve.

Quality gates before counsel handoff

The outcome metric is quality, measured by traceability rather than volume. A short chronology where every event cites both an obligation span and an evidence source outranks a long timeline built on uncited inference.

Automated checks include:

  • Span validation: every obligation reference resolves to an existing clause range in the contract corpus
  • Citation validation: every evidence pointer resolves to an ingested object with checksum and export metadata
  • Temporal consistency: events fall within the obligation's effective window unless flagged as pre-effective context
  • Conclusion hygiene: no row contains legal characterizations such as "material breach" unless sourced from an attorney work product explicitly included in the corpus

When obligations remain unmapped after reconciliation passes, the breach chronology section returns empty. The deliverable still includes the obligations inventory, the unmapped event log, and a mapping gap report explaining failed match reasons (missing definitions, party mismatch, ambiguous performance standard). Counsel still argues breach; the reconstruction supplies structured facts and explicit unknowns.

Downstream workflows consume the same spine. Contract evidence package assembly bundles the cited records for disclosure or meet-and-confer. Damages quantum estimator can attach loss theories to dated breach rows without re-deriving the factual sequence. Legal position stress tester runs adversarial passes against the chronology to surface weak links between duty, conduct, and remedy.

How litigation teams use the output

Transactional lawyers use the reconstruction during pre-suit assessment to see whether alleged failures align with identifiable duties and contemporaneous records. Litigation counsel uses it to draft statements of claim, respond to particulars, and prepare deposition outlines keyed to dates and sources. Experts receive a fact table that separates observed conduct from legal opinions.

The chronology is deliberately editable in review. Attorneys may suppress rows, add attorney notes, or fork a "counsel view" that layers legal theories atop the neutral fact base. Those edits are versioned so the underlying machine mapping remains auditable.

For large matters, teams often partition by obligation family (delivery, acceptance, payment, confidentiality, IP) and merge sub-chronologies after span and citation QA. Platform exports from Relativity or Everlaw can be re-ingested when new productions arrive; obligation registers from Ironclad can be refreshed when late-discovered amendments surface.

Limits and professional judgment

Reconstruction does not interpret force majeure, assess materiality, or compute cure periods unless those elements are encoded as explicit, citable rules tied to clause language. It does not replace privilege review. It does not authenticate evidence; it cites what was ingested and flags integrity metadata supplied by source systems.

The value is disciplined structure: a breach-oriented timeline where emptiness means unmappable, not missing, and every populated row answers two questions—which duty and which record. That is the minimum factual scaffolding counsel needs before arguing that a breach occurred at all.

[REDACTED]

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first