The Bench.← Algorithm lab

The Bench ALGO 1.0

Developed By Lawyers

Version 1.0.0 · September 30, 2026 · Proposed decision architecture and implemented prototype policy kernel.

Purpose and boundary

The Bench takes a two-sided dispute record and produces a reasoned, evidence-linked decision through the service's selected decision mode. This is an adjudication architecture, not merely an OnPoint similarity score repurposed as a verdict.

The implemented kernel validates supplied structured facts, legal-rule references, element findings, defenses, and remedy amounts. It then computes a proposed claim disposition and routes it. It does not yet extract evidence, research law, independently assess credibility, or generate findings. Those are explicit provider integration boundaries. The interactive lab uses synthetic documents, invented training rules, and prewritten findings, all labeled. Nothing generated by this release is a binding award.

The $100 tier is AI-only: no routine human merits review is inserted. The $500 tier requires human review of the proposed decision. The $1,000 tier has no specified decision model. Both configured tiers use the same evidence-verification and legal-analysis standards. Price is not a credibility, entitlement, or outcome feature.

Product-policy proposals, not established legal conclusions: the process gates below are proposed operational requirements. They do not establish that an AI-only arbitration decision is enforceable or that this workflow satisfies every jurisdiction's requirements. The current release cannot issue awards.

What carries over from OnPoint

The source reviewed is OnPoint's actual src/lib/algo.ts, its v3 tests, Claude's redesign instructions, and the later owner rulings from the shared conversation. The port preserves the v3 ranking policy rather than reverting to the earlier 40/35/20/5 formula or 20-point trial preference.

OnPoint mechanismThe Bench use
Fact importance 5 / 3 / 1Weight potentially dispositive, material, and contextual facts when selecting analogies
Exact source quotationsRequire source, page/paragraph identity, and exact character offsets
Law and posture gatesScreen whether an analogy can support a merits determination
Dispositive contradictionExclude a misleading factual analogy, not automatically a party's claim
Governing authority separate from analogueSelect the applicable rule independently of narrative similarity
No favorability bonusRetrieve and address authority adverse to either party
Version-sensitive document inputBind every audit to the complete record content hash
Coverage honestyPause proposed issuance when issue-specific research remains unresolved

The Bench does not exclude high-court authority from the governing-rule analysis. Its analogue preference for trial and intermediate appellate opinions is only a search aid. A pleading-stage decision accepting allegations is not automatically an appropriate merits analogue for deciding disputed facts.

1. Establish the procedural record

Before a proposed decision can pass the prototype gates, the record must specify: applicable agreement and scope verification; chosen decision mode accepted by both parties; both parties' participation; applicable governing law and rules version; closed evidence record; service eligibility and approved legal rule pack; and whether a hearing or live evidence is needed.

V1 intentionally has no nonparticipation/default-decision workflow. A missing response is not treated as agreement, proof, or a reason to award relief. A future default workflow would need separately designed service, notice, timing, evidentiary, and legal rules.

Unknown law can guide exploratory retrieval but cannot silently become the governing law of a proposed final decision. Unresolved authenticity, missing pages, untranslated material, or OCR problems should generate targeted requests before adjudication. The parser/OCR implementation remains pending.

2. Preserve and structure both parties' evidence

Intended ingestion: retain originals, cryptographic file hashes, extracted text, page mappings, and extraction method. Never replace a stored original with a generated summary. Keep PDF index, printed page, paragraph, section, and exhibit identifiers separate.

Current source schema stores id, kind, party, origin, pages, and textHash. The implemented hash covers the extracted pages; it is not an original-file authenticity certificate. Source references include sourceId, pageId, start, end, and quote. An exact span must match; fuzzy citation repair is not permitted.

Each fact records its proposition, 5/3/1 importance, status (allegation, testimony, contract term, stipulation, or judicial finding), supporting references, opposing references, resolution, and reason. A statement in an affidavit remains testimony unless a reasoned finding resolves it. Repeated copies or repeated assertions should not receive additional evidentiary weight. Document volume, verbosity, payment tier, and upload order are not ranking features.

The present kernel checks source integrity and structure. Semantic support, completeness, authenticity, and actual truth require additional analysis; a quotation occurring in a document proves only that the quotation occurs there.

3. Frame the claims, counterclaims, defenses, and remedies

Create a complete inventory from both parties' submissions before deciding anything. Each requested claim/counterclaim gets an ID. Each defense is explicitly associated with its target claim. The engine rejects missing or additional claim IDs relative to the inventory and rejects omitted defense IDs.

Each issue needs an approved, jurisdiction-specific rule pack: necessary elements, burden holder, burden of proof, defenses, available relief, and controlling sources. Do not infer one universal burden for all disputes. V1 fixtures use an invented rule solely for engineering tests; there is no approved production NY/NJ rule pack in this release.

A dispute may require statute, regulation, contract, and case law. The source schema can represent those materials, but retrieval is not connected. A count of similar cases is not a rule of law.

4. Research the law and factual analogies

Proposed retrieval sequence: fact-specific searches; doctrinal searches for governing authority; and posture-specific searches only where relevant to the issue. Expand recognized rule cases through a bounded local citation graph, with per-source deduplication and coverage accounting. The policy exposes a 150-candidate ceiling and a 15-finalist target. Actual retrieval, graph traversal, and finalist model reranking remain integrations to implement.

Owner constraints carry forward: DingDuff is excluded, paid sources are disabled, and NY/NJ and the identified federal/Delaware courts are the initial corpus focus. No national corpus is loaded by this release.

For each issue, retain the controlling rule sources and up to three useful factual analogies/contrasts. Record negative treatment, source, method, and check date. A blank citation search does not establish good law. Unknown or adverse history on governing authorities pauses proposed issuance; an uncertain analogue receives a qualified label and cannot independently establish the governing rule.

Analogue score:

max(0, 100 × (matched weights − 0.5 × distinguishable weights) / all fact weights)

Silence earns zero and stays in the denominator. A supported dispositive contradiction rejects that analogy. Incompatible law or merits posture also rejects it. Scores of at least 70 may be close if other checks pass; 50–under 70 are closest-available; below 50 are excluded. An unmatched dispositive fact prevents an unqualified close label.

Sort first by close versus qualified, then fixed five-point factual-score bands, then bounded preferences: trial +3, intermediate appellate +2, target jurisdiction +2, same posture +1. Then exact score, date, and stable ID break ties. These are provisional engineering parameters inherited from OnPoint, not validated legal-accuracy measurements.

5. Decide facts and apply the governing elements

The intended reasoning stage first analyzes each side's strongest supported account and then resolves necessary factual disputes using the applicable standard. It must distinguish insufficient proof after a fair opportunity to present evidence from an incomplete process requiring clarification.

For every element, output: rule references; burden and burden holder; relevant fact IDs; finding of proven/not proven/unresolved; explanation; opposing position; and response to that position. The current kernel verifies these supplied fields and rejects a proven element based on unresolved or not-established supporting facts.

Supplied element/defense findingsKernel disposition
All necessary claim elements proven, no successful or unresolved defeating defenseClaim upheld
At least one necessary claim element not provenClaim denied
A fully proven defeating defenseClaim denied
A necessary element or potentially successful defense remains unresolvedClarification required

V1 implements fully defeating defenses only. Partial defenses, comparative responsibility, limitation of damages, setoff, and alternative remedies need explicit typed extensions. Unsupported defense effects are rejected rather than guessed. Counterclaims use the same structure with reversed party roles.

A similarity score never becomes a win probability, a percentage of liability, or a substitute for an element finding. A poor or absent analogy does not erase an otherwise applicable governing rule.

6. Calculate relief separately

The v1 calculator supports principal in integer US cents. Every line must identify the claim, unique underlying loss, evidence references, amount requested, proposed amount, and reason. It rejects floating-point amounts, requested-amount overruns, duplicate recovery for the same loss, unsupported remedy kinds, and upheld claims with no remedy supplied.

Interest, fees, punitive relief, nonmonetary orders, and automatic setoff are not implemented. Later calculators must identify the legal/contractual basis, dates, rate convention, offsets, and caps rather than ask a language model to do arithmetic. Unsupported relief requires further work, not an invented rate or zero-cost assumption.

7. Audit the draft against the entire record

The intended audit is a separate critique stage. Check every dispositive assertion against the cited source; confirm complete claims/defenses coverage; seek adverse authority; distinguish evidentiary allegations from findings; recompute monetary relief; and test whether the reasoning changes merely because party labels or document order change.

The kernel requires an audit record covering semantic support and party symmetry. It binds that audit to the complete non-audit input hash as well as the revision. Editing an amount, fact, reason, document, or tier invalidates the previous audit. These fields are supplied assertions, not authenticated proof that a qualified reviewer or independent model performed the checks. Production must create them server-side and preserve reviewer/model identity.

The $100 path must not silently convert a failed audit into a paid human upgrade. Proposed behavior is to request necessary information or decline a decision under service rules. The $500 reviewer should receive the original record, all citations, contrary arguments, and flagged limitations, and should be able to revise or reject the draft. No reviewer authentication or approval endpoint is implemented yet.

8. Output and release states

The kernel returns needs_clarification, ai_draft_ready, or awaiting_human_review. Any failed process/research/audit gate makes proposedDecision null. Internal element analysis remains inspectable as preliminary analysis, never as a released award. All outputs carry isBindingAward: false and releaseEnabled: false in this release.

The future decision format should contain procedural authority and scope; issues; parties' positions; material findings with exact evidence references; governing rules; relevant analogies and distinctions; element-by-element application; disposition of each claim/defense; relief calculation; and decision-mode identification. An AI-only decision must not imply a lawyer reviewed the individual case. The brand line Developed By Lawyers describes the product, not a per-case review claim.

Whether and how to issue enforceable AI-only decisions is a separate launch decision requiring the applicable agreement and jurisdictional analysis. The Federal Arbitration Act's vacatur grounds include certain procedural misconduct and exceeding arbitral powers; this is context for keeping a complete record, not a conclusion that this prototype or an AI-only decision satisfies the Act. See 9 U.S.C. § 10(a)(3)–(4), https://www.law.cornell.edu/uscode/text/9/10 (accessed September 30, 2026). AAA's current AI Arbitrator describes human-issued awards; it is not evidence of approval for autonomous binding AI adjudication: https://www.adr.org/ai-arbitrator/ (accessed September 30, 2026).

Generation records and costs

engine/pipeline.mjs supplies a Node integration seam for extraction, research, assessment, and audit. A provider must supply each stage and return output, model, prompt version, token count, and cost. No provider implementation or API key is bundled.

Every generation gets an ID and a persisted pending record before invocation. Returned output is persisted before validation. Failures and completed results remain retrievable by run ID. Default budget is zero; a positive provider estimate is rejected before invocation unless an explicit budget is provided. Each provider must itself enforce its advertised token/cost limits; post-call validation cannot undo an unexpected vendor charge. Run budgets are not a production account-wide spending control. Production needs authenticated durable storage, atomic account-level budget reservation, encryption, retention/deletion policy, and scoped run URLs.

The interactive lab does no model generation, accepts no real case documents, and holds its deterministic simulation in memory until exported. It does not use the production-style journal. Run artifacts must not be committed to the repository.

Validation and next acceptance milestone

Current engineering tests cover exact-quote rejection; source hashes; tier routes; same-revision audit invalidation; missing parties; incomplete legal research; claim/defense omissions; contradictory facts; clause changes; remedy arithmetic; history and posture gates; deterministic ordering; and generation journaling/budget checks. These do not measure legal correctness or retrieval recall.

Before live adjudication, build at least 40 lawyer-graded disputes across the approved initial scope, with 25% held out from tuning. Include adverse outcomes, conflicting evidence, operative-clause edits, incomplete records, counterclaims, affirmative defenses, and procedural objections. Measure source-reference accuracy, material-fact attribution, governing-rule selection, adverse-authority retrieval, element application, outcome/amount agreement with the adjudicated benchmark, abstention quality, party-order invariance, cost, and latency. Report denominators and error examples. Hard failures include fabricated sources/quotes, omitted dispositive submissions, wrong-party remedies, unsupported relief, and any release despite a failed gate.

No lawyer-approved legal benchmark has been run for The Bench ALGO 1.0 yet. The five lab scenarios are synthetic engineering fixtures, not examples of measured AI accuracy.