@actuarial-ts/data 0.7.0 → 0.8.0

package/README.md

@@ -3,18 +3,23 @@
 Typed ingestion, preparation, and data-review boundaries for the actuarial-ts SDK. It supports loss-run/exposure CSVs, annual claim-development adaptation, triangle assembly, and generalized diagnostic review designed to support ASOP No. 23 work.
 
 ```bash
-npm install @actuarial-ts/data@0.7.0 @actuarial-ts/core@0.7.0
+npm install @actuarial-ts/data@0.8.0 @actuarial-ts/core@0.8.0
 ```
 
 Node 20+, ESM. Responsibility for the review and resulting actuarial work remains with the actuary.
 
+SDK 0.8 adds strict parsers, source mapping, externally staged revision
+history, and complete customization resource-policy validation. See the
+[0.8 adoption guide](https://github.com/yerromnitsuj/actng/blob/v0.8.0/docs/migrations/0.8-reusable-customization.md)
+and [customization reference](https://github.com/yerromnitsuj/actng/blob/v0.8.0/docs/reference/reusable-customization.md).
+
 ## Existing ingestion and triangle review
 
 `parseLossRunCsv`, `parseExposureCsv`, `adaptAnnualClaimDevelopment`, `triangleFromLongFormat`, `reviewClaimData`, and `reviewTriangles` return structured errors/findings rather than silently cleaning source records. Physical source-line numbers are retained where available.
 
 ## Diagnostic run boundary
 
-Use `validateDiagnosticRunInput` before `runValidatedMetricDiagnostics`. Validation parses the entire configuration atomically and compiles its definition; no partially validated run escapes.
+The example below uses the retained eager path: `validateDiagnosticRunInput` before `runValidatedMetricDiagnostics`. Validation parses the entire configuration atomically and compiles its definition; no partially validated run escapes. The compact path below uses the same input model and execution policies with a distinct evidence representation.
 
 ```ts
 import { runValidatedMetricDiagnostics, validateDiagnosticRunInput } from "@actuarial-ts/data";
@@ -59,7 +64,57 @@ Definitions add declarative `compare`, `reconcile`, `monotonic`, `layer-order`,
 
 Completed outcomes are owner-branded and include the exact prepared data, review receipt, run preset, dataset artifact, grouping, result, and two-gate receipt. Compliance provenance accepts only that completed object.
 
-See the [formula catalog](https://github.com/yerromnitsuj/actng/blob/v0.7.0/docs/reference/diagnostic-formulas.md) and [migration guide](https://github.com/yerromnitsuj/actng/blob/v0.7.0/docs/migrations/0.6-generalized-diagnostics.md).
+## Compact runs and paged review
+
+Introduced in 0.7.0, `validateDiagnosticRunInputCompact` followed by
+`runValidatedMetricDiagnosticsCompact` retains complete review evidence behind
+authenticated owners. Check `outcome.status` before using a completed run: a
+review-blocked result is `null`, while a metric-blocked outcome includes its
+diagnostic result but still cannot authorize provenance. Neither blocked path
+should be presented as a successfully reviewed analysis.
+
+Compact receipts have summary checks with `findingCount`, an `evaluations`
+store, and a `findings` store. They do not contain eager per-check finding arrays.
+Use the store from the same receipt throughout paging:
+
+| Need | Public API |
+|---|---|
+| Finding summaries without expanded source lists | `pageDiagnosticReviewFindings(receipt.findings, query)` from data |
+| Sources for one finding's stable index | `pageDiagnosticReviewFindingSources(receipt.findings, index, query)` from data |
+| Passed, triggered, and not-evaluated evaluation summaries | `pageDiagnosticReviewEvaluations(receipt.evaluations, query)` from core |
+| Sources for one evaluation | `pageDiagnosticReviewEvaluationSources` from core |
+
+Finding-source queries distinguish `context` and review `scope` sources. Page
+results disclose totals and continuation offsets; a summary's source count is
+not the source list. `getDiagnosticReviewFinding` and
+`iterateDiagnosticReviewFindings` provide full individual findings when needed,
+but can expand their source arrays. Do not collect every full finding merely to
+paginate it afterward.
+
+`getCompletedCompactDiagnosticRunInput` exposes the retained immutable input
+owner for a genuine completed run. Keeping that run alive also keeps its replay
+inputs alive; release obsolete runs when the host no longer needs them. Parsed
+JSON, spreads, and casts cannot recreate these owners. Use
+`createCompactDiagnosticRunIdentity` in compliance for compact completed runs;
+the eager provenance function is not interchangeable.
+
+See the runnable [compact adoption guide](https://github.com/yerromnitsuj/actng/blob/v0.8.0/docs/migrations/0.7-compact-diagnostics.md)
+and [replay/resource-policy reference](https://github.com/yerromnitsuj/actng/blob/v0.8.0/docs/reference/diagnostic-replay-stream.md).
+Compact representation preserves evidence; it is not a claim that an arbitrary
+large dataset or host memory budget has passed acceptance.
+
+## Compact diagnostic queries
+
+`createDiagnosticQueryContext` owns one compact run input, and
+`runDiagnosticQueryCompact` validates, prepares, reviews, calculates, and gates
+each requested scope. Queries can replace declared filters, cutoffs, expected
+cells, grouping, and evidence labels. Definition, source rows, review evidence,
+and execution policy stay fixed. Eligible clean aggregate selections reuse
+immutable preparation and exact review evidence; every other selection follows
+the ordinary compact preparation path. The API does not promise a latency or
+process-memory target.
+
+See the [formula catalog](https://github.com/yerromnitsuj/actng/blob/v0.8.0/docs/reference/diagnostic-formulas.md) and [migration guide](https://github.com/yerromnitsuj/actng/blob/v0.8.0/docs/migrations/0.6-generalized-diagnostics.md).
 
 ## License