How every document, fact, and legal argument in the matter is stored, related, and reasoned over — from the CRM records you edit to the RDF graph the rules engine judges.
01 · Architecture
The system deliberately separates the records people edit from the graph the engine reasons over. The CRM is the source of truth; the RDF graph is a faithful projection of it, rebuilt on demand so reasoning is never done against stale data.
Every object below is a real table in the workspace schema, edited through the Twenty GraphQL API (never raw SQL). This is where counsel reviews evidence, where emails land, where AI work product is filed. It holds state; it does not draw conclusions.
The CRM records are projected into a typed RDF graph governed by the ontology. rules.py runs SHACL integrity shapes, the court-ready bundle gate, and the readiness scorecard over it — writing append-only DecisionRecords so every ruling is versioned and reproducible.
02 · The spine
This is the load-bearing path of the whole model. A piece of evidence supports an assertion (a claimed fact); an assertion proves a legal element; elements compose a strategy. The Assertion is the hub that ties raw documents to legal theory.
gapForElement marks an element with no proof, and blocksStrategy flags the strategy it stalls. Nothing on this chain is trusted until a human approves it: every assertion and every artifact defaults to UNREVIEWED, and only counsel promotes it.03 · Object model
Field chips are colour-coded: governance / gate fields carry the review and provenance state, relation fields point at other objects, plain chips are attributes. Only the load-bearing fields are shown.
Every document in the matter. The governance-heavy object — it carries the source, approval, and authenticity state that decides whether a document can ever reach a judge.
A single claimed fact extracted from evidence — "the boiler serves Unit 1". The hub linking documents to legal elements, with a page/line citation back to the source.
A required element of a cause of action or strategy — e.g. §5015(a)(3) fraud, or "clear & unequivocal mandate" for contempt. Weighted by how much it moves the case.
The court case(s) — NY Supreme index numbers, consolidations, the parties and property units at issue.
Raw email intake before it becomes evidence. Carries the authentication material — DKIM verdict, content hash, and the real body (HTML now converted to text).
AI-generated work product — strategy scans, withheld-evidence analyses. Always marked machine-generated and held to the same counsel-review gate as evidence.
Dated procedural events — depositions, discovery demands, deadlines — that anchor "days elapsed" arguments and the chronology.
Case law with its material-fact factors, matched against the matter's facts to test whether a precedent actually controls.
The theories of the case — the narrative frames the strategies serve (fraud on the court, harassment/access obstruction).
An authenticated IMAP source feeding ImportedEmail. Credentials live in SecureVault, never in the record.
04 · Ontology
Our own namespace lp: defines the classes and relations, but every class crosswalks to an established standard via rdfs:subClassOf or skos:closeMatch — so the graph stays interoperable and the reasoning rests on recognised legal-informatics foundations rather than a bespoke schema.
The backbone of authenticity. lp:EvidenceArtifact is a prov:Entity; chain-of-custody, authentication and e-discovery events are each a prov:Activity; lp:authoredBy refines prov:wasAttributedTo.
Matter classification. lp:Matter is a skos:closeMatch of sali:Matter — the industry-standard practice/area taxonomy.
Document structure. lp:LegalDocument closeMatches akn:documentCollection; pleadings, motions, affidavits and orders subclass it.
Court-order obligations. lp:imposesDuty closeMatches lrml:Obligation and lp:prohibits closeMatches lrml:Prohibition — how an injunction's mandates become machine-checkable.
Discovery lifecycle. The edrmStage field tracks each item through the Electronic Discovery Reference Model stages.
Foundational legal vocabulary for persons, roles, and legal concepts underpinning the domain classes.
Usage/privilege policy (odrl:) and descriptive metadata (dct:) on artifacts.
SHACL shapes (shapes.ttl) are the integrity gate; SKOS is the crosswalk mechanism that keeps lp: aligned to every standard above.
lp:Injunction → lp:CourtOrder → lp:LegalDocument → lp:EvidenceArtifact → prov:Entity — an injunction inherits document structure, evidentiary governance, and provenance all at once.vocabularies.ttl defines ConceptSchemes for review-status, evidence-tier, document-type, confidence and strategy-type — and the flagship, Party Role. Plaintiff/defendant is a role played in a specific matter, not a fixed label on a person: the same party flips role across the consolidated actions — same party = PLAINTIFF in one index, DEFENDANT in a related action. It is modelled as a reified lp:PartyRole (party × matter × role — PLAINTIFF · DEFENDANT · PETITIONER · RESPONDENT · APPELLANT), following the LKIF-Core role pattern. Drifted CRM enum terms crosswalk to canonical concepts (COUNSEL_APPROVED → APPROVED) with no record migration.05 · Governance
The reason the model carries so many fields on EvidenceItem: an artifact must clear three separate questions before it can be relied on — where it came from, whether a human approved it, and whether it's authentic. These are stored as distinct fields and rendered as distinct badges.
How we know the document's date and origin — never assumed, only recorded from a verifiable source.
Human sign-off. Nothing self-approves — every item and assertion starts UNREVIEWED and only counsel promotes it.
Cryptographic integrity — a DKIM verdict for email, and a content hash sealing every file against tampering.
Governance isn't only about what comes in. The one irreversible outward action — sending mail to a party — is gated the same way: nothing reaches an outsider without a human admin.
The single sanctioned send path. It sends only if every recipient (To/Cc/Bcc) is on the trusted allowlist; any outside recipient (opposing counsel, the court, third parties) is queued as PENDING_ADMIN_APPROVAL and not sent until an admin releases it. Direct mail calls are neutralised so nothing can bypass it.
06 · Reasoning
Three layers run in order over the projected RDF, each writing versioned DecisionRecords. The engine never approves anything — it measures readiness and surfaces gaps for a human to act on.
Every EvidenceArtifact must carry a contentHash, a dateProvenance, and a counselReviewStatus; every EmailArtifact must carry a real DKIM verdict. Violations are hard failures — an item that can't prove its own integrity can't be counted.
An artifact is court-ready only if it is APPROVED and (DKIM PASS or already on the court record). This is what separates "we have it" from "we can put it in front of a judge".
For each legal element the engine computes approved-ready (proof counsel has cleared) versus potential (proof that exists but awaits review), then rolls them up per strategy by element weight — e.g. Valuation Attack 100% potential, PI Vacatur 89.5%, all 0% approved until counsel signs off.