The two questions users still ask
Legal platforms have become very good at the work around a matter. They take intake, extract facts from documents, draft letters and pleadings, manage deadlines and keep the file in order. Firms that use them work faster and with fewer errors in the paperwork.
The same users, at the same desk, still ask two questions the software does not answer: what is this matter worth, and how long will it take? They ask it at intake, when deciding whether to accept a matter. They ask it when setting settlement authority, when explaining options to a client, when deciding whether to seek funding and when planning the firm’s cash. Those are the decisions that determine whether the firm makes money, and today they are made on experience, a few remembered comparables and intuition.
This paper is for the platforms that serve those users. It explains what the court record adds, how to think about its value in the platform’s own terms, and how it is embedded without changing how the platform works.
Why drafting tools do not answer them
It is natural to ask a general-purpose model the valuation question, and many platforms already let users do so. The answers are fluent and often reasonable. They are also unstable: a sampled answer can differ each time the same question is asked, as the paper Same File, Same Number (WP-005) sets out.
A platform cannot put a number that moves in front of a client or into a settlement authority memo. The firm needs a figure that is the same every time the file is read, that comes with its uncertainty stated, and that was tested against how comparable matters actually resolved. That is a different kind of system from a drafting model, and it complements one rather than replacing it.
Drafting tools help a firm do the work. The record helps it decide which work is worth doing, and on what terms.
The value of a band
The value of adding estimates to a platform can be stated with one product of three terms.1
value of a band = decision volume × error cost × reduction in dispersion
- Decision volume is how many valuation-dependent decisions the platform’s users make in a year: intake accept or decline, settlement authority, funding requests, fee arrangements.
- Error cost is the average cost of getting one of those decisions wrong at today’s level of uncertainty: a matter accepted that loses money, a settlement taken too early or held too long, a fee priced below the work.
- Reduction in dispersion is how much a calibrated band narrows the uncertainty the decision is made under, compared with how it is made today.2
Decisions × amount at stake × what a wrong call costs × the share a band removes. Every figure follows from your inputs. Nothing you enter is stored or sent.
The framing matters for a platform because it locates the value with the user, where it belongs. The platform does not need to claim that its users will win more cases. It needs to show that its users make many decisions that depend on value and duration, that those decisions are expensive to get wrong, and that a calibrated band makes them less wrong. Each term can be measured for a real user base once estimates are in use.
Where the value lands inside a platform
| Moment in the workflow | Decision | What the record adds |
|---|---|---|
| Intake | Accept, decline or refer | Outcome path and duration band for comparable matters in this venue, before time is invested |
| Case strategy | Where to push, when to settle | Resolution path by stage, and how duration changes after key events |
| Settlement | Authority and timing | Settlement range with its median, labelled by source, and the cost of waiting |
| Client communication | Setting expectations | A band the client can understand, stated the same way every time |
| Firm finance | Cash planning and funding | Book-level timing of resolutions and the spread around it |
In each case the estimate sits beside the work the platform already does. A user reviewing an intake sees the band next to the extracted facts; a user preparing a settlement memo sees the range next to the draft. Nothing about the platform’s existing features changes. The estimate adds a number the user can rely on at the moment a decision is made, and the platform keeps ownership of the workflow, the user relationship and the interface in which the number appears. Firms see the figure where they already work, and the platform decides how prominently to show it, to whom, and at which step of each workflow.
How embedding works: files in, bands and reports out
Embedding is defined entirely at the level of inputs and outputs, which keeps it simple for the platform and keeps each side’s systems separate.
What the platform sends
The facts the platform already holds about a matter: case type, venue, stage, key dates, parties’ roles, and any documents the user chooses to include. The more of the record that is supplied, the narrower the band; a thin request still returns an answer, and an incomplete one never returns a higher figure than a complete one, as set out in WP-004.
What comes back
Outcome, duration and settlement bands with their labels: measure, population, as-of date, model and record version, and status. Where the platform wants it, a formatted report for the user and an audit trail for the firm. Because each figure carries its versions, the platform can regenerate any earlier answer exactly, which matters when a client or a court later asks how a number was reached.
How it is delivered
Through an API for platforms that render results in their own interface, and through reports for platforms that prefer to hand the user a finished document. Request and response formats are described in the developer documentation.
What Criterica never sees or keeps
A platform’s users trust it with confidential client material, and nothing about embedding the record should change that.
- Criterica receives only what the platform sends for a request. It has no access to the platform’s other data or users.
- Customer files are used for the customer’s request. They are not used to train shared models without the customer’s written agreement.
- No output names a counterparty, and no customer’s matters are visible to any other customer.
- Retention and deletion follow the terms agreed with the platform, and the security and governance pages set out the controls.
The governance controls behind these commitments are described on the governance page.
Measuring the value once estimates are live
The three terms in the value-of-information product are not left as assumptions. Once estimates are in use inside a platform, each one can be measured from the platform’s own activity, and the partnership is reviewed against those measurements.
- Decision volume is counted directly: the number of matters for which users requested an estimate at intake, at a settlement decision or at a funding request.
- Error cost is read from the firm’s own history: matters accepted that were later written off, settlements reopened, fees that fell below the time recorded on the matter.
- Reduction in dispersion is read from the bands themselves and checked against resolutions as they arrive: whether outcomes landed inside the stated bands as often as the bands claimed.
Because every estimate is fixed and versioned, this review compares what each user was told on a stated date with what later happened, without relying on anyone’s memory of the number. The same record lets a platform show its own customers, in its own terms, what the feature is worth to them, which is the strongest case a product team can make for it.
What to require of any provider
Whether a platform works with Criterica or with anyone else, the same requirements protect its users.
- The same request returns the same figure, every time, with its version.
- Uncertainty is shown as a calibrated band, with calibration evidence available on request.
- Every figure states its population, date and status.
- Removing information never raises a figure.
- Customer data is used only for the customer’s requests unless the customer agrees otherwise in writing.
A provider that meets these can sit inside a product that firms rely on for real decisions. The test in section 6 of WP-005 checks the first requirement in under an hour.
The question, as the reader has it
A product lead at a legal platform asks a practical question: if we add a valuation and duration estimate to the product, what changes for the people who use it, and how would we know? The firm user asks a related one: can I put this number in front of a client or a funder? A point estimate fails both readers. It gives the product lead nothing to measure, because a single number cannot be scored for how much uncertainty it removed, and it gives the firm user nothing to defend, because a single number does not say how far it could be wrong.
A band answers both. It can be scored against outcomes as they arrive, and it tells the user in the same view how much weight the number will bear.
What is measured
| Quantity | Unit | Population |
|---|---|---|
| Time to resolution | Months, as a median with P25 to P75 and P10 to P90 spans | Closed matters of the same case type, venue and stage, from filed court records |
| Settlement band | US dollars, a range with its median | Closed matters with a recorded amount, adjusted for the facts supplied |
| Probability of an event | A number from 0 to 1 over a stated horizon | Closed matters that could have had the event |
| Value of the band to a platform | US dollars per year, from the three-term product | The platform’s own users and their own decision history |
The first three rows are statements about the court record and carry their population and as-of date. The fourth is a statement about a platform and is measured from that platform’s own activity once estimates are in use; this paper shows the arithmetic with illustrative inputs only. Matters enter a comparison population only when the record shows how they ended.
How a number travels from the record to the platform
- Platform facts to structured event. Case type, venue, stage, key dates and any documents the user chooses to include become dated events. Parties and courts are resolved against a knowledge graph, so one actor is one node.
- Event to model class. Duration uses survival analysis, in the Kaplan-Meier and proportional-hazards tradition, because many comparable matters are still open. Event probabilities use calibrated probabilistic classification. Sparse venues use hierarchical partial pooling.
- Model class to calibrated output. Scores are recalibrated on held-out matters, and bands are fitted as quantile or conformal intervals so their stated coverage can be tested.
- Output to the platform’s screen. The band returns with its labels and versions. The same request returns the same figure, so the platform can show it the same way every time and regenerate any earlier answer.
Value of information is the lens for why this path is worth embedding.1 The expected gain from a piece of information is the difference between the best decision made with it and the best decision made without it. A band that is calibrated lowers the error of the decision; a band that is narrow but not calibrated raises it, which is why calibration, and not width, is what is validated first.
Validation design
Two things are validated, and they are validated at different times. The estimates are validated before release: models are frozen at a time cut and scored on matters filed after it, with the point-in-time boundary applied to every input so nothing known only later can inform an earlier estimate. The metric families are discrimination, calibration (reliability diagrams and Brier-type scores) and interval coverage. TN-003 explains how to read them.
The value to the platform is validated after launch, from the platform’s own record. Because each estimate is fixed, dated and versioned, the platform can compare what its users were told on a given date with what later happened, and check whether outcomes landed inside the stated bands as often as the bands claimed. Figure 1 is evidence of the arithmetic of the three-term product on illustrative inputs; Figure 2 is evidence of the interface: what goes in, what comes back, and that each request stands alone.
Scope and precision
The record adds a band for outcome, duration and settlement. It does not add a prediction of the realized dollars of a particular matter, and it does not state which party prevails from a disposition code; direction is read only from sources that record it (WP-006). The value-of-information figure is illustrative until it is measured on a real user base.
- Data lag: the record reflects filings up to its as-of date, and the estimate is re-issued when the record moves.
- Censoring: open matters are not outcomes; survival methods account for them.
- Venue sparsity: where comparable matters are few, the band widens and the status says so.
What a reader can reproduce
The value-of-information example is a product of three terms and can be recomputed by hand, or with the calculator above, using the reader’s own volume, error cost and reduction in dispersion. A platform can test the stability of any provider with the repeat-request protocol in WP-005. Reproducing a matter-level band requires the platform, because it depends on the record version and model version returned with the figure; with those two, any earlier answer can be regenerated exactly.