Heuristic AI — Actor-Rule Extraction Engine v0.3

1 · Define the actors first

Each actor gets a reasoning profile. For a litigation matter the actor map includes:

2 · Convert every artifact into structured events

Do not start with "summarise documents." Start with event extraction. Every email, motion, order, affidavit, valuation, filing or transcript becomes:

ArtifactID · Date · Source · Actor · Recipient/Target · ArtifactType
ActionType · ClaimMade · ReliefRequested · LegalBasis · EvidenceCited
Contradictions · Outcome · NextActorResponse · ReliabilityLevel · PrivilegeStatus

Example:

Artifact: 2019-02-28 email        Actor: Bleich
ActionType: Sale-position / commercial-motive statement
ClaimMade: "My interest is simply..."
InferredRuleCandidate: Bleich uses litigation posture to support sale leverage.
SupportingArtifacts: later injunction filings, sale discussions, valuation behaviour.
CounterEvidence: any document showing independent non-sale motive.
Confidence: Medium until counsel-approved.

3 · Separate four types of reasoning rule

Four layers — do not mix them.

A · Legal rules (actual court tests)

IF motion = preliminary injunction
THEN elements = likelihood of success + irreparable harm + balance of equities + undertaking

Relevance (FRE 401) and authentication (FRE 901) are themselves rule-based: evidence is relevant if it makes a consequential fact more/less probable, and must be shown to be what its proponent claims.

B · Procedural rules (timing / court process)

IF injunction entered AND undertaking required AND undertaking missing/defective
THEN possible vacatur / modification / enforcement issue

C · Actor-behaviour rules (inferred from repeated conduct — hypotheses, not law)

IF adverse party faces sale/debt pressure AND litigation can delay/control disposition
THEN adverse party seeks injunctive leverage

D · Commercial-incentive rules (why actors behave as they do)

IF debt > ordinary market value AND strategic-buyer value > ordinary value
THEN rational move = delay + competitive tension + avoid forced sale

4 · Build an actor-rule card for every participant

ActorID · ActorType · KnownObjectives · KnownConstraints · RepeatedClaims
RepeatedMoves · Contradictions · CredibilityRisks · PressurePoints
DocumentsReliedUpon · DocumentsAvoided · LikelyNextMove · CounterMove
Confidence · EvidenceBasis

5 · Use a move–response–outcome graph

Litigation is a sequence, not a snapshot:

For every move store: MoveID · Actor · MoveType · LegalTheory · EvidenceUsed · ImmediateObjective · OpponentResponse · CourtResponse · Result · WasSuccessful · WhySuccessful · WhyFailed. This lets the engine learn rules like:

IF court accepts governance framing AND economic-motive evidence not introduced
THEN injunction risk increases
IF credibility contradiction is authenticated AND tied to a required injunction element
THEN vacatur probability increases

6 · Convert artifacts into claim–support–attack structures

Every meaningful statement becomes a legal assertion with its supports, its attacks, and its legal use — more useful than a summary because it tells counsel exactly how a fact can be used and attacked.

Assertion: Adverse party's litigation position was sale-leverage-driven.
Supports: 2019 email · later sale discussions · injunction timing · debt pressure · buyer interest.
Attacks: governance explanation · independent legal basis · lack of authentication · privilege/hearsay/relevance.
Legal use: unclean hands · bad faith · vacatur · credibility impeachment.

7 · Learn rules by "same actor, same pattern"

One artifact → a CANDIDATE rule. Three+ consistent artifacts → a STABLE hypothesis. A court order or adverse admission → a high-confidence rule.

8 · Build rule confidence levels

Do not let the system say "this is true" too early.

A rule must not drive a motion unless it is at least SUPPORTED + counsel-approved + source-linked. For court-facing use: COUNSEL_APPROVED + authenticated + admissibility-tiered + non-impeached. (This is the same discipline as the reasoning engine's OTOC + counsel-in-loop staging gate.)

9 · Model the judge differently

Build a judicial reasoning extraction model, never a "judge psychology model." Its rules come only from written orders, transcript comments, hearing questions, objection rulings, credited/ignored facts, relief granted/denied, and procedural warnings.

Issue: PI / vacatur / contempt / appraisal
Court-applied test: elements required
Facts credited / ignored: which assertions accepted / not addressed
Procedural defects: undertaking, service, timing, standing, jurisdiction
Rule learned: IF party fails to address element X THEN court likely rejects/narrows relief

10 · Model opposing counsel as a playbook

Opposing counsel reasoning is tactical, not truth-seeking. Per filing extract: theory · burden imposed · facts emphasised/avoided · procedural pressure · framing · relief · fallback · settlement leverage. Learned rules:

IF weak merits evidence      THEN emphasise emergency / irreparable harm
IF economic motive exposed   THEN reframe as governance / compliance / protection
IF client has debt pressure  THEN seek time-control relief
IF story conflicts w/ emails THEN attack relevance / authentication

11 · Model your own side brutally

The engine must learn your side's weaknesses — missed arguments, underdeveloped evidence, late filings, unsupported allegations, unapproved assertions, credibility risks, admissions, overstatements, procedural/privilege exposure. This prevents "advocacy fantasy":

IF our strongest motive evidence is not authenticated
THEN do not make fraud/unclean-hands the lead argument yet
IF debt pressure creates apparent desperation
THEN court may discount commercial-motive arguments unless tied to legal elements

12 · Add commercial-actor reasoning

Litigation strategy and asset monetisation are linked. Each commercial actor gets an incentive rule:

13 · Technical architecture

PROV-O gives a standard way to describe provenance (entities, activities, agents) so reliability can be assessed later; SALI gives a consistent legal taxonomy for matters, work, documents and organisations. Both already underpin the LegalPresence ontology layer, so this engine composes with the existing lp_ontology and reasoning-staging schemas.

14 · The rule schema

RuleID · RuleType (LEGAL/PROCEDURAL/TACTICAL/COMMERCIAL/EVIDENTIARY)
Actor · Trigger · Condition · Action · ExpectedOutcome
SourceArtifacts · CounterExamples · Confidence · LastValidated
CounselApproval · AdmissibilityStatus

RuleID: R-ADV-004        RuleType: TACTICAL     Actor: Adverse party
Trigger: Asset-sale pressure
Condition: Litigation can delay/control disposition
Action: Frame dispute as governance/emergency issue
ExpectedOutcome: Injunction leverage / settlement pressure
SourceArtifacts: email_2019_02_28, motion_2024_xx, order_2025_01_17
Confidence: SUPPORTED   CounselApproval: pending   Admissibility: mixed

15 · Use outcome validation

A rule is useful only if it predicts or explains outcomes. For each rule ask: did it explain a past move? predict the next filing? was it accepted/rejected by the court? repeated by the opponent? did it expose a contradiction or a missing element? did counsel agree it was usable? If not — downgrade it.

16 · Actor next-move prediction

17 · The litigation reasoning matrix

18 · What to automate now

1. Actor extraction — who acted, what they said, what they wanted, its legal/commercial effect, who responded, what happened next.
2. Move classification — pleading · threat · admission · denial · delay · leverage · valuation · settlement · governance claim · credibility attack · procedural defect · commercial offer.
3. Rule induction — group repeated move-patterns by actor.
4. Counsel validation — valid/invalid · privileged · admissible/not · useful for cross/motion/settlement.
5. Motion application — rules feed motion viability, only after approval.

19 · What not to do

20 · The immediate deliverable

An Actor Reasoning Rulebook: (1) actor map · (2) case timeline · (3) artifact inventory · (4) legal tests by motion · (5) actor move library · (6) inferred rules by actor · (7) supporting artifacts · (8) counter-evidence · (9) contradictions · (10) credibility exposure · (11) procedural gaps · (12) commercial incentives · (13) next likely moves · (14) best counter-moves · (15) counsel approval queue.

Highest-value first outputs:

1. Judge reasoning map — what the court needs for vacatur, contempt, appraisal, sale relief.
2. Opposing-party playbook — sale leverage, governance framing, delay/control tactics.
3. Our weakness map — unauthenticated assertions, admissions, unclean-hands/estoppel exposure.
4. Motion-specific evidence queue — exactly which artifact must be approved to flip each motion from potential to bringable.
5. Cross-examination map — actor statements that conflict across time.

21 · SWOT analysis

Assessed against what LegalPresence already runs — not in the abstract.

22 · Building it on our stack — from marked-up cases across workspaces

Mostly extension, not new-build. The engine maps onto what already exists:

The build, in four layers

1. Per-case (per workspace). Each case imports into its own workspace (multi-tenant); its artifacts are marked up (document_concept, ontology). inference_engine extracts events + candidate actor-rules per actor → OTOC-gated → SHACL-validated → written to lp_reasoning_staging as PENDING → counsel approves.
2. Ontology additions (SHACL + SKOS). Add SKOS ActorType / RuleType / MoveType schemes; an lp:Rule class carrying the rule schema; and SHACL ActorShape / RuleShape / EventShape + a RuleUsableShape that enforces the usability rule as a constraint — confidence ≥ SUPPORTED ∧ counselApproval = APPROVED ∧ sourceArtifacts ≥ 1 ∧ not IMPEACHED. The discipline becomes machine-checked, not a policy note.
3. Cross-workspace aggregation (the one genuinely new piece). A shared rule graph aggregates abstracted rules across cases — trigger→action pattern + de-identified actor type + confidence — behind a privilege firewall: source artifacts stay in their case workspace (referenced by ID, access-controlled); only the abstraction crosses. A rule rises to STABLE when the same pattern recurs across multiple cases.
4. The rules engine consumes it. Add a layer_actor_rules to rules.py: given a matter, apply the (case + shared) rule graph to produce next-move predictions and the reasoning matrix — as staged, counsel-reviewed outputs, never auto-fired.

23 · Temporal reasoning — dates, sequence & the response chain

Litigation is not a set of facts; it is a timed sequence of responses. Every motion, affidavit, evidence presentation, hearing and order occurs in response to a prior issue, action, or decision — a party files a motion because of a prior order, presents evidence because of a prior claim, delays because of a prior deadline. Date and time are therefore first-class, not metadata.

Three reasons dates/times are load-bearing:

1. Actor rules are conditional on prior events. The rule shape is inherently temporal: IF prior event X (order / evidence / demand) THEN actor responds with move Y. Without ordering you cannot tell a response from a coincidence.
2. Timing is itself evidence. A motion filed days after a sale demand reveals motive; a two-year delay reveals strategy; an affidavit dated after the fact it describes is impeachable. The gap between events is a signal.
3. Procedure and admissibility are date-driven. Deadlines, undertakings, service, appeal windows are dates — and a date is only usable if its provenance is sound (dateProvenance: NYSCEF stamp / email header / order date / OCR-extracted — the discipline already enforced on evidence).

Already modelable on our stack. The timelineEvent object carries a relationshipType enum — FOLLOWS · CAUSED_BY · CAUSES · CONTRADICTS · CORROBORATES · SUPPORTS · DISPROVES · CITES · GENERATED_EXHIBIT · DISPUTED — which is the response-chain vocabulary; every artifact already carries documentDate + dateProvenance. The engine orders events by authenticated date, then links each move to the prior event it responds to (CAUSED_BY/FOLLOWS), turning the move→response→outcome graph (§5) into a real temporal DAG — so the inference engine learns "in response to X, this actor does Y," not merely "X and Y both happened."

24 · Case-history map — actors, documents & learned rules

How the engine learns from a single case history, made human-visible: an Obsidian-style graph of the Bleich matter. Actors (navy) author documents (grey); documents support or contradict one another; and each rule (gold) the engine induced traces back to the exact documents and actors that justify it. Drag the nodes — the layout is force-directed.

R-ADV-003 (Bleich swore rooftop HVAC is his sole source) traces to the Bleich deposition + POLISE schedule that disprove it; R-JUDGE-001 (grant a conditional, liftable PI) traces to Justice Rosado's 1/17/2025 order. Across many marked-up cases, the rules that recur become the cross-case rulebook.