Agent Fabric: added the Status Timeline Compression / Run-Length Encoding (RLE) agent — deterministic run-length encoding that compresses a per-slot status stream into canonical (value, length) runs, with every encoding a sourced self-consistent lossless run list (it decodes back exactly), a re-deriving canonical RLE, and never an autonomous write-back (the 110th agent)
ShippedDetails
Added the one-hundred-and-tenth agent on the fabric — status-timeline-rle-agent, a DETERMINISTIC (no-Claude) platform / data-substrate stream-compression agent on the PHI-adjacent platform & data-substrate plane, reusing the existing data-plane tier as a SIBLING to the Huffman Coding and Timeline Merge agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY the heart of the service is RUN-LENGTH ENCODING: a single left-to-right pass that coalesces each maximal block of identical consecutive values into one (value, length) run — the canonical, provably-unique RLE of the stream, losslessly REVERSIBLE (decoding the runs reproduces the exact original). It is NOT the Huffman agent's OPTIMAL PREFIX CODING (a FREQUENCY-based variable-length code over the alphabet — this is CONSECUTIVE-RUN coalescing, order-dependent, no frequency model), NOT the Coverage Heatmap agent's DIFFERENCE-ARRAY RANGE ACCUMULATION, NOT the Rolling Census Peak agent's SLIDING-WINDOW MAXIMUM, NOT the Timeline Merge agent's K-WAY MERGE (which interleaves multiple sorted streams — this compresses ONE stream), and NOT the List Reconciliation agent's LONGEST COMMON SUBSEQUENCE. In a new pure lib/status-timeline-rle.ts, evaluateStatusTimeline(request) takes a per-slot STATUS stream (device state / bed-occupancy / monitoring status) and DETERMINISTICALLY run-length-encodes it into (value, length) runs, reading off the run count, the compression ratio (originalLength / runCount), the longest run, and the dominant status — with disposition compressible (fewer runs than slots) or incompressible (one run per slot — no consecutive repeats, RLE gains nothing). The exact, reversible run list is the invariant this service reports and defends. It COMPLEMENTS, not duplicates, the Huffman agent (frequency-based prefix coding) and the Timeline Merge agent (multi-source interleave): this run-length-compresses one status stream. TIME IS DATA: the statuses are plain values and the encoding is a pure function of them (no clock, no randomness), so the same request always yields the same determination. An encoding — compressible / incompressible — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresStewardReview:true, autoWritten:false); an incompressible disposition is a LEGITIMATE FINDING (no consecutive repeats to coalesce), NOT a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.statusrle.encoding-sourced (signal statusEncodingSourced, violating value false) blocks an encoding that isn't a real, lossless accounting — DECODING the runs (each value repeated `length` times, in order) must reproduce EXACTLY the submitted stream (same values, order, and length), every run length ≥ 1, honest counts/ratio/longest-run/dominant-status — a fabricated run, a wrong length, or a reordered decode is a corrupted encoding — the sourced + self-consistency gate (mirroring the Huffman Agent's code-sourced and the Rolling Census Peak Agent's windows-sourced) — backed by the pure guard encodingSourced; policy.statusrle.runs-canonical (signal statusRunsCanonical, violating value false) blocks a non-canonical run list — re-running RLE over the submitted statuses must reproduce the EXACT run list; RLE has a UNIQUE canonical form (maximal runs — adjacent runs never share a value), so an OVER-SPLIT run (a single run reported as two adjacent same-value runs) is non-canonical EVEN THOUGH IT STILL DECODES CORRECTLY — this is the load-bearing correctness gate, and it re-derives the canonical runs INDEPENDENT of the reported runs (so an over-split-but-decodable encoding fails canonical ONLY while a fabricated run that doesn't decode fails sourced only — the two gates are isolable) (mirroring the Rolling Census Peak Agent's deque-exact and the Huffman Agent's code-optimal) — backed by the guard runsCanonical; and policy.statusrle.no-autonomous-write (signal statusNoAutonomousWrite, violating value false) blocks a determination that autonomously wrote the compressed timeline back to a source of record, replaced the raw stream, or persisted the encoding (autoWritten:true — each is a data-write that must be authorized) or did not require steward review (requiresStewardReview:false) — the agent COMPRESSES on paper, and every encoding is a RECOMMENDATION requiring a data steward to confirm — backed by the guard noAutonomousWrite (mirroring the Timeline Merge Agent's no-autonomous-merge and the Rolling Census Peak Agent's no-autonomous-divert; the harmful action is enforced-off). It IS PHI-adjacent — the statuses reference a device / bed monitoring timeline — so it is on the HIPAA-audit policy (phiAccessed:true throughout) and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/status-timeline-rle/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — statusrle.receive-stream → statusrle.encode → statusrle.classify-disposition → statusrle.log-audit — with phiAccessed:true, returning the StatusTimelineDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Status Timeline panel (a compressible preset over a 16-slot RPM device stream → 5 runs (3.2× compression), longest run 5, dominant 'normal'; an incompressible preset where statuses alternate every slot → one run per slot; a stable preset that collapses to a single run; plus doesn't-decode / over-split / auto-written governance-block presets), a seeded statusrle.receive-stream→encode→classify-disposition→log-audit trace showing the compressible case (runCount 5, compressionRatio 3.2, requiresStewardReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'one hundred ten agents', with the Status Timeline Compression agent on the data-plane tier alongside the Huffman Coding agent) all reflect it. Menopause-relevant: a remote-monitoring device that streams a menopause patient's status once a minute across a long stable stretch — normal, normal, …, a brief high, back to normal — is exactly the run-heavy timeline this RLE compacts to a handful of runs for efficient storage and transmission, without ever overwriting the raw stream on its own. Frontend tests green (+ status-timeline-rle runLengthEncode / decode-round-trip / one-run-per-slot / empty, evaluate compressible / incompressible / stable / determinism, and three-guards-on-produced with over-split-decodes-but-non-canonical + doesn't-decode + zero-length-run + encoding-sourced-vs-runs-canonical-isolation + mis-merged + auto-written + skipped-review guard cases, the route's envelope / three governance blocks / compressible + incompressible + stable happy paths with a PHI-adjacent trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to one hundred ten agents); the stream is a clearly-labeled illustrative synthetic — NOT a certified time-series / telemetry compression system (real telemetry compression uses delta / delta-of-delta encoding, dictionary methods, Gorilla-style float compression, and lossy downsampling — not a bare RLE over illustrative status labels). Lint + build clean.
Agent Fabric: added the Rolling Census Peak / Sliding-Window Maximum (Monotonic Deque) agent — deterministic monotonic deque that computes the peak census in every trailing window of a unit's occupancy readings and flags over-capacity windows, with every report a sourced self-consistent per-window peak (cross-checked by direct scanning), a re-deriving exact deque, and never an autonomous diversion (the 109th agent)
ShippedDetails
Added the one-hundred-and-ninth agent on the fabric — rolling-census-peak-agent, a DETERMINISTIC (no-Claude) care-coordination capacity-monitoring agent on the PHI-adjacent patient/clinical plane, reusing the existing care-coordination tier as a SIBLING to the Coverage Heatmap and Access Anomaly agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY the heart of the service is the MONOTONIC DEQUE sliding-window maximum: maintain a double-ended queue of candidate indices whose readings are decreasing, pop from the back every index whose reading is ≤ the incoming reading, push the new index, and drop the front once it falls out of the window — the front is always the window's maximum, O(1) amortized per window and O(n) overall. It is NOT the Access Anomaly agent's SLIDING-WINDOW COUNTING (a fixed-window EVENT COUNT — this is the sliding-window EXTREMUM via a monotonic deque), NOT the Coverage Heatmap agent's DIFFERENCE-ARRAY RANGE ACCUMULATION (per-slot occupancy from range-adds — this is the rolling MAX over a window of an existing series), NOT the Peak-Window agent's KADANE MAXIMUM-SUBARRAY (a max contiguous SUM — this is a max VALUE per fixed-width window), NOT the Fenwick / Benefit Accumulator agent's PREFIX SUMS, and NOT the SLA Worklist agent's EARLIEST-DEADLINE-FIRST SCHEDULING. In a new pure lib/rolling-census-peak.ts, evaluateRollingCensus(request) takes per-slot CENSUS readings, a trailing WINDOW width k, and a CAPACITY threshold, and DETERMINISTICALLY computes the peak census in every trailing window via the monotonic deque, flags the over-capacity windows, reads off the overall peak, and derives the disposition: within-capacity (no window breaches capacity) or over-capacity (some window peaks above it). The per-window peak is the invariant this service reports and defends. It COMPLEMENTS, not duplicates, the Coverage Heatmap agent (per-slot concurrent coverage) and the Access Anomaly agent (windowed event counts): this reports the rolling peak occupancy. TIME IS DATA: the readings + window size are plain numbers and the report is a pure function of them (no clock, no randomness), so the same request always yields the same determination. A report — within-capacity / over-capacity — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresSupervisorReview:true, autoDiverted:false); an over-capacity disposition is a LEGITIMATE FINDING (a capacity breach), NOT a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.rollingcensus.windows-sourced (signal censusWindowsSourced, violating value false) blocks a report whose per-window maxima aren't the true peaks — each windowMaxes[i] must equal max(readings[i .. i+k-1]), checked by DIRECT per-window scanning (INDEPENDENT of the monotonic-deque method), exactly readingCount - k + 1 windows, the overCapacityWindows exactly the breaching windows, peakCensus / windowCount / readingCount honest, and the disposition following — a fabricated window max, a mis-listed over-capacity window, or a dishonest peak is a corrupted report — the sourced + self-consistency gate (mirroring the Coverage Heatmap Agent's coverage-sourced and the Benefit Accumulator Agent's ledger-sourced) — backed by the pure guard windowsSourced; policy.rollingcensus.deque-exact (signal censusDequeExact, violating value false) blocks a mis-derived maxima array — re-running the MONOTONIC DEQUE sliding-window maximum over the submitted readings + window size must reproduce the reported windowMaxes array exactly, window for window — this is the load-bearing correctness gate, and it re-runs the monotonic deque INDEPENDENT of the reported maxima (and of the sourced gate's direct scanning), so the two gates CROSS-CHECK the same per-window truth by TWO DIFFERENT METHODS: a fabricated maxima array that still reports the right over-capacity windows fails deque only, and a genuine-but-mislabeled disposition fails sourced only — the two are isolable (mirroring the Coverage Heatmap Agent's accumulation-exact and the Benefit Accumulator Agent's accumulator-exact) — backed by the guard dequeExact; and policy.rollingcensus.no-autonomous-divert (signal censusNoAutonomousDivert, violating value false) blocks a determination that autonomously diverted admissions, triggered surge staffing, or acted on a peak (autoDiverted:true — each is an operational action that must be authorized) or did not require supervisor review (requiresSupervisorReview:false) — the agent MONITORS on paper, and every report is a RECOMMENDATION requiring a nursing supervisor to confirm — backed by the guard noAutonomousDivert (mirroring the Coverage Heatmap Agent's no-autonomous-staff and the Interpreter Assignment Agent's no-autonomous-dispatch; the harmful action is enforced-off). It IS PHI-adjacent — the census references a care unit's occupancy — so it is on the HIPAA-audit policy (phiAccessed:true throughout) and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/rolling-census-peak/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — rollingcensus.receive-readings → rollingcensus.peak → rollingcensus.classify-disposition → rollingcensus.log-audit — with phiAccessed:true, returning the RollingCensusDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Rolling Census Peak panel (an over-capacity preset over 10 hourly readings with a 3-hour window and capacity 18 → window maxes [15,20,20,20,19,16,17,18], four windows over capacity, peak 20; a within-capacity preset that never breaches; a spike preset exercising the deque's back-eviction with a decreasing run then a spike; plus fabricated-max / mis-derived / auto-diverted governance-block presets), a seeded rollingcensus.receive-readings→peak→classify-disposition→log-audit trace showing the over-capacity case (peakCensus 20, overCapacityCount 4, requiresSupervisorReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'one hundred nine agents', with the Rolling Census Peak agent on the care-coordination tier alongside the Coverage Heatmap agent) all reflect it. Menopause-relevant: watching a menopause-clinic's rolling occupancy across a busy day — seeing which 3-hour windows peak above the safe capacity as walk-ins and scheduled visits stack up — so a supervisor can flex capacity before wait times or safety suffer, is exactly the rolling peak this monotonic-deque sliding-window maximum computes, without ever diverting a patient on its own. Frontend tests green (+ rolling-census-peak slidingWindowMax / deque-vs-direct-agreement / back-eviction / window-too-large, evaluate over-capacity / within-capacity / spike / determinism, and three-guards-on-produced with fabricated-max + mis-listed-windows + dishonest-peak + windows-sourced-vs-deque-exact-isolation + mis-derived + auto-diverted + skipped-review guard cases, the route's envelope / three governance blocks / over-capacity + within-capacity + spike happy paths with a PHI-adjacent trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to one hundred nine agents); the readings are a clearly-labeled illustrative synthetic — NOT a certified capacity-management / patient-flow system (real census management weighs acuity, staffed vs licensed beds, isolation & telemetry needs, anticipated discharges, and boarding — not a bare rolling max over illustrative counts). Lint + build clean.
Agent Fabric: added the Coverage Heatmap / Difference-Array Range Accumulation agent — deterministic difference array that computes per-slot concurrent staffing coverage from overlapping shift intervals and flags under-staffed slots, with every heatmap a sourced self-consistent count (cross-checked by direct counting), a re-materializing exact accumulation, and never an autonomous staffing action (the 108th agent)
ShippedDetails
Added the one-hundred-and-eighth agent on the fabric — coverage-heatmap-agent, a DETERMINISTIC (no-Claude) care-coordination capacity-visibility agent on the PHI-adjacent patient/clinical plane, reusing the existing care-coordination tier as a SIBLING to the Schedule Conflict and Caseload Balancing agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY the heart of the service is the DIFFERENCE ARRAY (the imos / range-update technique): to add `staff` to every slot in [start, end), increment diff[start] and decrement diff[end] — an O(1) range update — then a single PREFIX-SUM pass materializes the concurrent coverage at every slot in O(T), so applying m overlapping intervals costs O(m + T), not O(m·T). It is NOT the Fenwick / Benefit Accumulator agent's POINT-UPDATE + PREFIX-QUERY tree (the dual problem — this is RANGE-UPDATE + full MATERIALIZE), NOT the Schedule Conflict agent's GREEDY INTERVAL SELECTION (which picks a max non-overlapping subset — this COUNTS overlaps per slot), NOT the Peak-Window agent's KADANE MAXIMUM-SUBARRAY (a max contiguous sum — this is per-slot occupancy), NOT the Caseload Balancing agent's BIN-PACKING, and NOT the Batch Partition agent's LINEAR PARTITION. In a new pure lib/coverage-heatmap.ts, evaluateCoverageHeatmap(request) takes a set of staffing COVERAGE INTERVALS (each { label, start, end, staff }) over a slot count and a REQUIRED MINIMUM, and DETERMINISTICALLY materializes the concurrent coverage at every slot via the difference array, finds the UNDER-STAFFED slots (below the minimum), reads off min/max, and derives the disposition: fully-covered (every slot meets the minimum) or understaffed (some slot below). The per-slot concurrent coverage is the invariant this service reports and defends. It COMPLEMENTS, not duplicates, the Schedule Conflict agent (double-booking guard) and the Caseload Balancing agent (panel capacity fill): this visualizes concurrent coverage across a schedule. TIME IS DATA: the intervals + slot indices are plain numbers and the heatmap is a pure function of them (no clock, no randomness), so the same request always yields the same determination. A heatmap — fully-covered / understaffed — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresManagerReview:true, autoStaffed:false); an understaffed disposition is a LEGITIMATE FINDING (a coverage gap), NOT a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.coverageheat.coverage-sourced (signal coverageSourcedSignal, violating value false) blocks a heatmap whose per-slot coverage isn't the true count — each coverage[t] must equal the sum of `staff` over every submitted interval whose [start, end) contains t, checked by DIRECT interval counting (INDEPENDENT of the difference-array method), the understaffedSlots exactly the below-min slots, minCoverage / maxCoverage / slotCount / intervalCount honest, and the disposition following — a fabricated coverage value, a mis-listed under-staffed slot, or a dishonest min/max is a corrupted heatmap — the sourced + self-consistency gate (mirroring the Benefit Accumulator Agent's ledger-sourced and the Interpreter Assignment Agent's assignment-sourced) — backed by the pure guard coverageSourced; policy.coverageheat.accumulation-exact (signal coverageAccumulationExact, violating value false) blocks a mis-materialized heatmap — re-applying the intervals to a fresh DIFFERENCE ARRAY and prefix-summing must reproduce the reported coverage array exactly, slot for slot — this is the load-bearing correctness gate, and it re-runs the difference-array range accumulation INDEPENDENT of the reported coverage (and of the sourced gate's direct counting), so the two gates CROSS-CHECK the same per-slot truth by TWO DIFFERENT METHODS: a fabricated coverage that still reports the right under-staffed slots fails accumulation only, and a genuine-but-mislabeled disposition fails sourced only — the two are isolable (mirroring the Benefit Accumulator Agent's accumulator-exact and the Interpreter Assignment Agent's cost-optimal) — backed by the guard accumulationExact; and policy.coverageheat.no-autonomous-staff (signal coverageNoAutonomousStaff, violating value false) blocks a determination that autonomously scheduled, adjusted, or dispatched staff (autoStaffed:true — each is a staffing action that must be authorized) or did not require manager review (requiresManagerReview:false) — the agent VISUALIZES on paper, and every heatmap is a RECOMMENDATION requiring a staffing manager to confirm before any coverage changes — backed by the guard noAutonomousStaff (mirroring the Interpreter Assignment Agent's no-autonomous-dispatch and the Benefit Accumulator Agent's no-autonomous-adjust; the harmful action is enforced-off). It IS PHI-adjacent — the intervals reference care-unit staffing — so it is on the HIPAA-audit policy (phiAccessed:true throughout) and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/coverage-heatmap/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — coverageheat.receive-schedule → coverageheat.accumulate → coverageheat.classify-disposition → coverageheat.log-audit — with phiAccessed:true, returning the CoverageHeatmapDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Coverage Heatmap panel (an understaffed preset over a 12-slot care-unit day with four overlapping shifts against a required min of 2 → coverage [2,2,3,3,3,3,1,1,3,3,2,2], slots 6–7 below the minimum; a fully-covered preset where the intervals blanket every slot; a spike preset with many overlapping short intervals → a midday spike to 5 and understaffed edges; plus fabricated-coverage / mis-materialized / auto-staffed governance-block presets), a seeded coverageheat.receive-schedule→accumulate→classify-disposition→log-audit trace showing the understaffed case (minCoverage 1, understaffedCount 2, requiresManagerReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'one hundred eight agents', with the Coverage Heatmap agent on the care-coordination tier alongside the Schedule Conflict agent) all reflect it. Menopause-relevant: seeing which hours of a menopause-clinic day dip below the required nurse / MA coverage as morning and afternoon shifts overlap and hand off — so a manager can plug the gap before it becomes a wait-time or safety problem — is exactly the per-slot concurrency this difference-array heatmap computes, without ever moving a staff member on its own. Frontend tests green (+ coverage-heatmap accumulateCoverage / coverageByDirectCount-agreement / zero-width-and-zero-staff / empty, evaluate understaffed / fully-covered / spike / determinism, and three-guards-on-produced with fabricated-coverage + mis-listed-slots + dishonest-min-max + coverage-sourced-vs-accumulation-exact-isolation + mis-materialized + auto-staffed + skipped-review guard cases, the route's envelope / three governance blocks / understaffed + fully-covered + spike happy paths with a PHI-adjacent trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to one hundred eight agents); the intervals are a clearly-labeled illustrative synthetic — NOT a certified workforce-management / staffing system (real staffing weighs skill mix, acuity-adjusted ratios, licensure, breaks & meal relief, union rules, and float pools — not a bare count of overlapping intervals). Lint + build clean.
Agent Fabric: added the Interpreter Assignment / Optimal Assignment (Hungarian Algorithm) agent — deterministic Hungarian algorithm that matches interpreters to concurrent appointments at minimum total cost, with every assignment a sourced self-consistent one-to-one matching, a re-optimizing cost, and never an autonomous dispatch (the 107th agent)
ShippedDetails
Added the one-hundred-and-seventh agent on the fabric — interpreter-assignment-agent, a DETERMINISTIC (no-Claude) care-coordination assignment agent on the PHI-adjacent patient/clinical plane, reusing the existing care-coordination tier as the operational SIBLING of the Language Access & Health Equity agent (which decides WHETHER a qualified interpreter is required; this decides WHICH interpreter covers WHICH appointment at least total cost) — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY the heart of the service is the HUNGARIAN ALGORITHM (Kuhn–Munkres): the O(n³) combinatorial method that finds a minimum-cost perfect matching in a bipartite graph by maintaining dual potentials and augmenting along tight-edge alternating paths until every row is matched. It is EMPHATICALLY DISTINCT from the two matching agents it sits near: NOT the PCP Matching agent's GALE–SHAPLEY STABLE MATCHING (which produces a STABLE matching from two-sided PREFERENCE lists — no costs, no global optimum, and stability, not minimum total cost, is its property) and NOT the Caseload Balancing agent's WORST-FIT-DECREASING BIN-PACKING (an unordered greedy capacity fill, not a one-to-one optimal matching). It is also NOT the Referral Throughput agent's MAX-FLOW, NOT the Network Build-Out agent's MINIMUM SPANNING TREE, NOT the Batch Partition agent's LINEAR PARTITION, NOT the Outreach agent's 0/1 KNAPSACK, and NOT the Care Routing agent's DIJKSTRA'S SHORTEST PATH. In a new pure lib/interpreter-assignment.ts, evaluateInterpreterAssignment(request) takes a set of qualified INTERPRETERS, a set of concurrent APPOINTMENTS, and a COST matrix (travel + wait + skill-mismatch, or an UNAVAILABLE sentinel when an interpreter can't cover an appointment), and DETERMINISTICALLY computes the MINIMUM-TOTAL-COST one-to-one ASSIGNMENT via the Hungarian algorithm on a padded square matrix (unavailable / padded cells given a large finite stand-in so the solver never prefers them; a match landing on such a cell is reported unmatched) — reporting the pairings, the total cost, any uncoverable appointments, and the disposition: assignable (every appointment covered with a finite-cost interpreter) or infeasible (some appointment has no qualified interpreter). The minimum total assignment cost is the invariant this service reports and defends. It COMPLEMENTS, not duplicates, the PCP Matching agent (stable member↔PCP matching) and the Caseload Balancing agent (panel capacity fill): this is the optimal one-to-one assignment. TIME IS DATA: the costs are plain numbers and the assignment is a pure function of them (no clock, no randomness — ties broken by a stable row/column order), so the same request always yields the same determination. An assignment — assignable / infeasible — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresCoordinatorReview:true, autoDispatched:false); an infeasible disposition is a LEGITIMATE FINDING (a coverage gap), NOT a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.interpasg.assignment-sourced (signal interpAssignmentSourced, violating value false) blocks an assignment that isn't a real one-to-one matching — each pairing using a SUBMITTED interpreter + appointment, no interpreter or appointment used twice, each cost equal to the SUBMITTED matrix cell and finite (not the UNAVAILABLE sentinel), the totalCost equal to the sum of the chosen cells, the unmatched list exactly the uncovered appointments, and the disposition following — a fabricated pairing, a reused interpreter, or an overstated cost is a corrupted assignment — the sourced + self-consistency gate (mirroring the Benefit Accumulator Agent's ledger-sourced and the Network Build-Out Agent's tree-sourced) — backed by the pure guard assignmentSourced; policy.interpasg.cost-optimal (signal interpAssignmentOptimal, violating value false) blocks a sub-optimal assignment — re-running the HUNGARIAN ALGORITHM over the submitted cost matrix must reproduce the reported totalCost (and disposition) — this is the load-bearing correctness gate, and it recomputes the minimum total cost INDEPENDENT of the reported pairings (it compares the scalar optimum, since different optimal assignments can tie on total cost — so a fabricated assignment that still reports the optimal cost fails sourced only, and a real-but-sub-optimal assignment fails optimal only — the two gates are isolable) (mirroring the Benefit Accumulator Agent's accumulator-exact and the Network Build-Out Agent's cost-optimal) — backed by the guard assignmentOptimal; and policy.interpasg.no-autonomous-dispatch (signal interpNoAutonomousDispatch, violating value false) blocks a determination that autonomously booked, dispatched, or notified an interpreter (autoDispatched:true — each is a scheduling action that must be authorized) or did not require coordinator review (requiresCoordinatorReview:false) — the agent ASSIGNS on paper, and every assignment is a RECOMMENDATION requiring a language-access coordinator to confirm — backed by the guard noAutonomousDispatch (mirroring the Benefit Accumulator Agent's no-autonomous-adjust and the Referral Throughput Agent's no-autonomous-route; the harmful action is enforced-off). It IS PHI-adjacent — the appointments reference member encounters — so it is on the HIPAA-audit policy (phiAccessed:true throughout) and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/interpreter-assignment/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — interpasg.receive-roster → interpasg.assign → interpasg.classify-disposition → interpasg.log-audit — with phiAccessed:true, returning the InterpreterAssignmentDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Interpreter Assignment panel (an assignable preset over three interpreters + three appointments → the min-total-cost matching of 12, NOT the greedy per-appointment pick; a greedy-trap preset where the naive cheapest-per-appointment pick would double-book but the Hungarian optimum spreads them for a lower total; an infeasible preset where one appointment has no qualified interpreter; plus reused-interpreter / sub-optimal / auto-dispatched governance-block presets), a seeded interpasg.receive-roster→assign→classify-disposition→log-audit trace showing the assignable case (totalCost 12, requiresCoordinatorReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'one hundred seven agents', with the Interpreter Assignment agent on the care-coordination tier alongside the Language Access agent) all reflect it. Menopause-relevant: staffing a morning of concurrent menopause-clinic visits — a Spanish telehealth consult, a Mandarin in-person visit, an Arabic follow-up — with the on-call interpreters at the least total travel + wait cost, and surfacing the appointment that has no qualified interpreter, is exactly the optimal assignment this Hungarian solver computes, without ever booking an interpreter on its own. Frontend tests green (+ interpreter-assignment solveAssignment optimal-matching / uncoverable / greedy-trap, evaluate assignable / infeasible / determinism, and three-guards-on-produced with reused-interpreter + unavailable-cell + overstated-cost + assignment-sourced-vs-cost-optimal-isolation + sub-optimal + auto-dispatched + skipped-review guard cases, the route's envelope / three governance blocks / assignable + infeasible + greedy-trap happy paths with a PHI-adjacent trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to one hundred seven agents); the costs are a clearly-labeled illustrative synthetic — NOT a certified interpreter-scheduling / workforce system (real interpreter scheduling weighs certification & specialty, modality, union & labor rules, travel logistics, and member language preference — not a bare cost matrix). Lint + build clean.
Agent Fabric: added the Benefit Accumulator Ledger / Fenwick-Tree Prefix Sums agent — deterministic Fenwick tree that tallies a member's running benefit accumulator and locates the OOP-max crossover claim, with every ledger a sourced self-consistent accounting, a re-deriving exact accumulator, and never an autonomous adjustment (the 106th agent)
ShippedDetails
Added the one-hundred-and-sixth agent on the fabric — benefit-accumulator-agent, a DETERMINISTIC (no-Claude) payer-operations accumulator-ledger agent on the PHI-bearing payer & plan operations plane, reusing the existing payer-operations tier as a SIBLING to the Member Cost-Share, Claims Adjudication, and Audit Sample agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY the heart of the service is the FENWICK TREE (Binary Indexed Tree): a cumulative-frequency data structure supporting point updates and prefix-sum queries in O(log n), plus a binary lower-bound descent that finds the first index whose prefix sum reaches a threshold in O(log n). It is NOT the Member Cost-Share agent's COST-SHARING WATERFALL (which splits a SINGLE claim across deductible / coinsurance / OOP for one date of service — this is a CUMULATIVE data structure over a SEQUENCE of claims with prefix-sum + find-by-threshold queries), NOT the Audit Sample agent's RESERVOIR SAMPLING, NOT the Duplicate-Claim Screen agent's BLOOM FILTER, NOT the MLR Rebate agent's LARGEST-REMAINDER APPORTIONMENT, NOT the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS, and NOT the Peak-Window agent's KADANE MAXIMUM-SUBARRAY. In a new pure lib/benefit-accumulator.ts, evaluateBenefitAccumulator(request) takes an ORDERED sequence of applied claim amounts and an OUT-OF-POCKET MAXIMUM, and DETERMINISTICALLY computes the running cumulative totals and locates the CROSSOVER claim — the first at which the running total reaches/exceeds the OOP max — via a Fenwick-tree lower-bound descent (amounts scaled to integer cents so the compares are exact) — reporting the per-claim running totals, the total applied, the crossover index (or -1), the remaining-before-OOP-max, and the disposition: under-oop-max (never crosses) or oop-max-met (crosses at some claim, after which the plan pays 100%). The running prefix sums and the crossover index are the invariants this service reports and defends. It COMPLEMENTS, not duplicates, the Member Cost-Share agent (which splits a single claim across the cost-sharing waterfall): this tallies the running accumulator across many claims. TIME IS DATA: the amounts + OOP max are plain numbers and the ledger is a pure function of them (no clock, no randomness), so the same request always yields the same determination. A ledger — under-oop-max / oop-max-met — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresAnalystReview:true, autoAdjusted:false); an oop-max-met disposition is a LEGITIMATE FINDING (the member reached their OOP maximum), NOT a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.benefitacc.ledger-sourced (signal benefitLedgerSourced, violating value false) blocks a ledger that isn't a real, self-consistent accounting — each runningTotals[k] must equal the sum of appliedAmounts[0..k], the reported totalApplied equal to the final running total, the crossoverIndex either -1 or a valid submitted-claim index, remainingBeforeOopMax equal to max(0, oopMax - totalApplied), and the disposition following — a fabricated running total, a mis-summed ledger, or an out-of-range crossover is a corrupted accounting — the sourced + self-consistency gate (mirroring the Audit Sample Agent's sample-sourced and the Duplicate-Claim Screen Agent's filter-sourced) — backed by the pure guard ledgerSourced; policy.benefitacc.accumulator-exact (signal benefitAccumulatorExact, violating value false) blocks a mislocated crossover — re-building the FENWICK TREE from the submitted amounts and re-querying must reproduce every prefix sum, and the CROSSOVER index located by the tree's binary lower-bound descent must equal the reported crossoverIndex — this is the load-bearing correctness gate, and it re-derives the prefix sums AND the crossover INDEPENDENT of the reported running totals (it descends the tree, not the reported array; a mislocated crossover mis-states when the plan starts paying 100% — the member's liability — so a fabricated ledger that still reports the right crossover fails sourced only, and a real-but-mislocated crossover fails exact only — the two gates are isolable) (mirroring the Audit Sample Agent's selection-reproducible and the Duplicate-Claim Screen Agent's membership-exact) — backed by the guard accumulatorExact; and policy.benefitacc.no-autonomous-adjust (signal benefitNoAutonomousAdjust, violating value false) blocks a determination that autonomously posted, adjusted, or paid against a member's real accumulator (autoAdjusted:true — each is a benefit-adjustment action that must be authorized) or did not require analyst review (requiresAnalystReview:false) — the agent COMPUTES on paper, and every ledger is a RECOMMENDATION requiring a benefits analyst to confirm before anything touches the member's real accumulator — backed by the guard noAutonomousAdjust (mirroring the Audit Sample Agent's no-autonomous-audit and the Duplicate-Claim Screen Agent's no-autonomous-reject; the harmful action is enforced-off). It IS PHI-adjacent — the ledger references a member's claims — so it is on the HIPAA-audit policy (phiAccessed:true throughout) and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/benefit-accumulator/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — benefitacc.receive-ledger → benefitacc.accumulate → benefitacc.classify-disposition → benefitacc.log-audit — with phiAccessed:true, returning the BenefitAccumulatorDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Benefit Accumulator panel (an oop-max-met preset over six claims against a $3,000 OOP max → the running total crosses at the fifth claim; an under-oop-max preset where the total stays below the max with a remaining balance reported; an immediate-crossover preset where one large first claim meets the max; plus fabricated-total / mislocated-crossover / auto-adjusted governance-block presets), a seeded benefitacc.receive-ledger→accumulate→classify-disposition→log-audit trace showing the oop-max-met case (totalApplied 3550, crossoverIndex 4, requiresAnalystReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'one hundred six agents', with the Benefit Accumulator agent on the payer & plan operations plane alongside the Member Cost-Share agent) all reflect it. Menopause-relevant: tracking a member's running out-of-pocket accumulation across a year of menopause-care claims — HRT, labs, specialist visits — and pinpointing the claim at which they hit their OOP maximum (so the plan pays 100% thereafter) is exactly what this Fenwick accumulator computes, without ever adjusting the member's real accumulator on its own. Frontend tests green (+ benefit-accumulator FenwickTree point-add / prefix-sum / lower-bound, runningTotalsOf / crossoverViaFenwick, evaluate oop-max-met / under / immediate / determinism, and three-guards-on-produced with fabricated-total + dishonest-total + out-of-range-crossover + ledger-sourced-vs-accumulator-exact-isolation + mislocated-crossover + disagreeing-prefix + auto-adjusted + skipped-review guard cases, the route's envelope / three governance blocks / oop-max-met + under + immediate happy paths with a PHI-adjacent trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to one hundred six agents); the amounts are a clearly-labeled illustrative synthetic — NOT a certified benefits-accumulator / claims-payment system (real accumulator processing weighs the full benefit design — embedded vs aggregate family deductibles, network tiers, carve-outs, EOB reversals — plan-year resets, and an authoritative accumulator store — not a bare prefix-sum over illustrative amounts). Lint + build clean.
Agent Fabric: added the Audit Sample Selection / Reservoir Sampling (Algorithm R, Seeded) agent — deterministic single-pass reservoir sampling that draws a reproducible, uniform k-record audit sample from a stream, with every sample a sourced self-consistent subset, a re-runnable seeded draw, and never an autonomous audit (the 105th agent)
ShippedDetails
Added the one-hundred-and-fifth agent on the fabric — audit-sample-agent, a DETERMINISTIC (no-Claude) payer-operations compliance-sampling agent on the PHI-bearing payer & plan operations plane, reusing the existing payer-operations tier as a SIBLING to the Claims Adjudication, Fraud-Waste-Abuse, and Duplicate-Claim Screen agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY the heart of the service is RESERVOIR SAMPLING (Vitter's Algorithm R): fill a reservoir with the first k items, then for each subsequent item at 0-indexed position i draw j in [0, i] and replace reservoir[j] if j < k; after one pass over a stream of unknown / unbounded length, every item has been retained with uniform probability k/n, without ever holding the whole population in memory. It is NOT the Duplicate-Claim Screen agent's BLOOM FILTER (a membership test, not a uniform draw), NOT the Outreach Prioritization agent's 0/1 KNAPSACK (a value-maximizing subset, not an equal-probability sample), NOT the SLA Worklist agent's EARLIEST-DEADLINE-FIRST SCHEDULING, NOT the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS, NOT the Contact Rate Limit agent's TOKEN BUCKET, and NOT the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE. In a new pure lib/audit-sample.ts, evaluateAuditSample(request) takes a STREAM of record ids (claims / charts flagged for a compliance audit), a target sample size k, and an explicit SEED, and DETERMINISTICALLY draws a k-record sample via Algorithm R with a SEEDED PRNG (mulberry32 — no OS randomness) — reporting the selected ids, the population size, the effective sample size (min(k, n)), the uniform inclusion probability (k/n), the seed, and the disposition: sampled (n > k) or full-population (n ≤ k → the whole population is selected). The randomness being seeded is the whole point: the sample is fully REPRODUCIBLE — the same stream + k + seed always yields the same records, which is what makes an audit sample DEFENSIBLE (an auditor, or a regulator, can re-run it and get the identical set). The uniform inclusion probability and the reproducibility of the seeded draw are the invariants this service reports and defends. It COMPLEMENTS, not duplicates, the Fraud-Waste-Abuse and Duplicate-Claim Screen agents (which flag records): this selects a defensible SAMPLE of records to audit. TIME IS DATA: the ids + k + seed are plain data and the draw is a pure function of them (a seeded PRNG, no clock), so the same request always yields the same sample. A sample — sampled / full-population — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresAuditorReview:true, autoAudited:false); a full-population disposition is a LEGITIMATE FINDING (the population is at most k), NOT a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.auditsample.sample-sourced (signal auditSampleSourced, violating value false) blocks a sample that isn't a real subset of the submitted stream — every selected id appearing in the submitted recordIds (no fabricated id), no id selected more times than it appears, the sample size equal to min(sampleSize, populationSize), the reported populationSize equal to the stream length, the inclusionProbability equal to effectiveSampleSize / populationSize, and the disposition following — a fabricated id, a duplicate pick, or a mis-sized sample is a corrupted draw — the sourced + self-consistency gate (mirroring the Duplicate-Claim Screen Agent's filter-sourced and the Contact Rate Limit Agent's replay-sourced) — backed by the pure guard sampleSourced; policy.auditsample.selection-reproducible (signal auditSelectionReproducible, violating value false) blocks a cherry-picked or otherwise unreproducible draw — re-running the seeded RESERVOIR SAMPLING over the submitted stream + (sampleSize, seed) must reproduce the EXACT sample (same ids, same order) — this is the load-bearing correctness gate, and it re-runs Algorithm R INDEPENDENT of the reported sample (so a fabricated-but-in-population sample fails reproducibility only, and a real seeded draw with a fabricated id fails sourced only — the two gates are isolable) (mirroring the Duplicate-Claim Screen Agent's membership-exact and the Contact Rate Limit Agent's throttle-exact) — backed by the guard selectionReproducible; and policy.auditsample.no-autonomous-audit (signal auditNoAutonomousAudit, violating value false) blocks a determination that autonomously opened, adjudicated, flagged, or acted on a sampled record (autoAudited:true — each is an audit action that must be authorized) or did not require auditor review (requiresAuditorReview:false) — the agent SELECTS on paper, and every sample is a RECOMMENDATION of WHICH records to pull, requiring a compliance auditor to run the actual audit — backed by the guard noAutonomousAudit (mirroring the Duplicate-Claim Screen Agent's no-autonomous-reject and the Contact Rate Limit Agent's no-autonomous-send; the harmful action is enforced-off). It IS PHI-adjacent — record ids are PHI-adjacent — so it is on the HIPAA-audit policy (phiAccessed:true throughout) and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/audit-sample/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — auditsample.receive-population → auditsample.select → auditsample.classify-disposition → auditsample.log-audit — with phiAccessed:true, returning the AuditSampleDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Audit Sample panel (a sampled preset drawing 5 of 20 claim ids with a fixed seed → each with a 0.25 inclusion probability; a reseed preset over the same population with a different seed → a different reproducible sample, showing the seed (not chance) determines the draw; a full-population preset where the population (4) is smaller than the requested sample (10); plus fabricated-id / cherry-picked / auto-audited governance-block presets), a seeded auditsample.receive-population→select→classify-disposition→log-audit trace showing the sampled case (effectiveSampleSize 5, requiresAuditorReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'one hundred five agents', with the Audit Sample agent on the payer & plan operations plane alongside the Claims Adjudication and Duplicate-Claim Screen agents) all reflect it. Menopause-relevant: pulling a defensible, reproducible sample of HRT-titration or menopause-visit claims for an SIU or quality audit — one a regulator can re-run and get the identical records — is exactly what this seeded reservoir sampler produces, without ever opening a chart on its own. Frontend tests green (+ audit-sample mulberry32 determinism, reservoirSample subset / whole-population / k=0 / different-seed, evaluate sampled / full-population / determinism, and three-guards-on-produced with fabricated-id + mis-sized + duplicate-pick + sample-sourced-vs-selection-reproducible-isolation + cherry-picked + wrong-seed + auto-audited + skipped-review guard cases, the route's envelope / three governance blocks / sampled + full-population + reseed happy paths with a PHI-adjacent trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to one hundred five agents); the ids are a clearly-labeled illustrative synthetic — NOT a certified statistical-sampling / audit system (real audit sampling weighs stratification, RAT-STATS / OIG methodology, confidence intervals, and dollar-unit / probability-proportional-to-size designs — not a bare uniform reservoir over illustrative ids). Lint + build clean.
Agent Fabric: added the Duplicate-Claim Pre-Screen / Bloom-Filter Membership Test agent — deterministic Bloom filter that pre-screens incoming claim ids against processed ids (definitely-new vs possibly-duplicate), with every screen a sourced self-consistent filter, a re-deriving membership with no false negatives, and never an autonomous rejection (the 104th agent)
ShippedDetails
Added the one-hundred-and-fourth agent on the fabric — duplicate-claim-screen-agent, a DETERMINISTIC (no-Claude) payer-operations claims pre-screen agent on the PHI-bearing payer & plan operations plane, reusing the existing payer-operations tier as a SIBLING to the Claims Adjudication agent — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY the heart of the service is the BLOOM FILTER: a space-efficient PROBABILISTIC set-membership structure. It is NOT the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE (an EXACT two-roster diff — this is a probabilistic one-sided membership pre-screen with a tunable false-positive rate and NO per-key storage), NOT the Source Consensus agent's BOYER–MOORE MAJORITY VOTE, NOT the Timeline Merge agent's K-WAY MERGE, NOT the Audit Log Integrity agent's HASH CHAIN, NOT the Identifier Validation agent's MODULAR-ARITHMETIC CHECKSUM, and NOT the Code Taxonomy agent's TRIE LONGEST-PREFIX MATCH. In a new pure lib/duplicate-claim-screen.ts, evaluateDuplicateScreen(request) takes a set of already-PROCESSED claim ids and a batch of INCOMING claim ids plus a Bloom config (bit size m + hash count k), and DETERMINISTICALLY builds a Bloom filter over the processed ids (setting the k double-hashed bits per id, via a fixed seeded FNV-1a — no randomness) and screens each incoming id: all k bits set ⇒ POSSIBLY-DUPLICATE (route to the authoritative exact check), any bit clear ⇒ DEFINITELY-NEW (provably never processed — a Bloom filter has NO false negatives) — reporting the per-id verdicts, the possible-duplicate / definitely-new tallies, the bit array + set-bit count, and the estimated false-positive rate ((1 − e^(−k·n/m))^k), with disposition all-clear (none flagged) or possible-duplicates (some flagged). The one-sided guarantee (no false negatives) and the honest false-positive rate are the invariants this service reports and defends. It COMPLEMENTS, not duplicates, the Enrollment Reconciliation agent (an exact keyed set-difference): this is a fast probabilistic pre-filter run BEFORE the exact check. TIME IS DATA: the ids + config are plain data and the filter is a pure function of them (a fixed seeded hash, no clock), so the same request always yields the same determination. A screen — all-clear / possible-duplicates — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresAdjudicatorReview:true, autoRejected:false); a possible-duplicates disposition is a LEGITIMATE FINDING (some ids need the exact check) that ALWAYS defers to it, NOT a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.dupscreen.filter-sourced (signal dupScreenFilterSourced, violating value false) blocks a plan that isn't a real, self-consistent Bloom filter — the reported bit array must be the EXACT insert of the submitted processed ids with the submitted (m, k), the setBitCount honest, each result's id one of the submitted incoming ids (all covered, in order, none fabricated), each verdict consistent with the array (possibly-duplicate iff all k bits set), the tallies matching, and the disposition following — a fabricated bit, a mis-tallied count, or a contradicting verdict is a corrupted screen — the sourced + self-consistency gate (mirroring the Contact Rate Limit Agent's replay-sourced and the Referral Throughput Agent's flow-sourced) — backed by the pure guard filterSourced; policy.dupscreen.membership-exact (signal dupScreenMembershipExact, violating value false) blocks a mislabeled verdict — re-building the Bloom filter from the submitted processed ids + config and re-querying every incoming id must reproduce the reported verdict for each, and LOAD-BEARINGLY there must be NO FALSE NEGATIVE (any incoming id that IS one of the processed ids must be reported possibly-duplicate, never definitely-new — reporting a known duplicate as new would let a duplicate claim through, the one failure a Bloom filter must never make), and the false-positive-rate estimate must equal the standard formula — this is the load-bearing correctness gate, and it re-derives the membership INDEPENDENT of the reported bit array (so a fabricated array that still reports the right verdicts fails filter-sourced only, and a false negative fails membership-exact only — the two gates are isolable) (mirroring the Contact Rate Limit Agent's throttle-exact and the Referral Throughput Agent's throughput-optimal) — backed by the guard membershipExact; and policy.dupscreen.no-autonomous-reject (signal dupScreenNoAutonomousReject, violating value false) blocks a determination that autonomously rejected, denied, or paid a claim (autoRejected:true — each is an adjudication action that must be authorized) or did not require adjudicator review (requiresAdjudicatorReview:false) — the agent PRE-SCREENS on paper, a possibly-duplicate is a ROUTING SIGNAL to the exact check (never a denial), and every screen is a RECOMMENDATION requiring a claims adjudicator to confirm — backed by the guard noAutonomousReject (mirroring the Contact Rate Limit Agent's no-autonomous-send and the Referral Throughput Agent's no-autonomous-route; the harmful action is enforced-off). It IS PHI-adjacent — claim ids are PHI-adjacent — so it is on the HIPAA-audit policy (phiAccessed:true throughout) and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/duplicate-claim-screen/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — dupscreen.receive-batch → dupscreen.screen → dupscreen.classify-disposition → dupscreen.log-audit — with phiAccessed:true, returning the DuplicateScreenDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Duplicate-Claim Pre-Screen panel (a possible-duplicates preset over 6 processed + 5 incoming ids on a 64-bit / 3-hash filter → 3 possible-duplicate (all re-submissions caught, no false negatives) / 2 definitely-new; an all-clear preset where every incoming id is new; a deliberately-undersized (16-bit) filter preset illustrating the space/accuracy trade-off with a false positive routed safely to the exact check; plus fabricated-array / false-negative / auto-rejected governance-block presets), a seeded dupscreen.receive-batch→screen→classify-disposition→log-audit trace showing the possible-duplicates case (possibleDuplicateCount 3, requiresAdjudicatorReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'one hundred four agents', with the Duplicate-Claim Pre-Screen agent on the payer & plan operations plane alongside the Claims Adjudication agent) all reflect it. Menopause-relevant: a re-submitted HRT-titration or lab claim arriving in the same cycle as the original is exactly the duplicate this Bloom pre-screen flags for the exact check — fast, at scale, with no false negatives — without ever denying a claim on its own. Frontend tests green (+ duplicate-claim-screen buildBloomBits no-false-negative / determinism, estimateFalsePositiveRate formula, evaluate possible-duplicates / all-clear / saturated-false-positive / determinism, and three-guards-on-produced with fabricated-array + contradicting-verdict + false-negative + wrong-FP-rate + filter-sourced-vs-membership-exact-isolation + auto-rejected + skipped-review guard cases, the route's envelope / three governance blocks / possible-duplicates + all-clear + saturated happy paths with a PHI-adjacent trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to one hundred four agents); the ids are a clearly-labeled illustrative synthetic — NOT a certified claims-dedup / payment-integrity system (real duplicate-claim detection weighs the full claim key — member, provider, DOS, procedure, units — adjustment / void logic, and an authoritative claims store — not a bare Bloom pre-screen over illustrative ids). Lint + build clean.
Agent Fabric: added the Member Contact Rate Limiting / Token-Bucket Throttle agent — deterministic token-bucket that replays a member's outbound contact attempts to permit or throttle each under a frequency cap, with every plan a sourced order-preserving replay, a re-simulating exact throttle, and never an autonomous send (the 103rd agent)
ShippedDetails
Added the one-hundred-and-third agent on the fabric — contact-rate-limit-agent, a DETERMINISTIC (no-Claude) care-coordination contact-governance agent on the PHI-adjacent patient/clinical plane, reusing the existing care-coordination tier as a SIBLING to the Outreach Prioritization, Referral Throughput, and Scheduling agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY the heart of the service is the TOKEN-BUCKET RATE-LIMITING algorithm: a bucket holds up to `capacity` tokens and refills continuously at `refillPerHour` tokens/hour (never above capacity); each attempt, processed in time order, first accrues the refill earned since the previous attempt, then — if at least one whole token is available — consumes one token and is PERMITTED, otherwise is THROTTLED. It is NOT the Outreach Prioritization agent's 0/1 KNAPSACK (which selects WHICH members to contact under a capacity budget — this governs HOW OFTEN one member may be contacted over time), NOT the Access Anomaly agent's SLIDING-WINDOW COUNTING (a fixed-window event count with no continuous refill or token reservoir), and NOT the SLA Worklist agent's EARLIEST-DEADLINE-FIRST SCHEDULING, the Referral Throughput agent's MAX-FLOW, the Network Build-Out agent's MINIMUM SPANNING TREE, the Care Routing agent's DIJKSTRA'S SHORTEST PATH, or the Schedule Conflict agent's GREEDY INTERVAL SELECTION. In a new pure lib/contact-rate-limit.ts, evaluateContactRateLimit(request) takes a chronologically-ordered sequence of outbound contact ATTEMPTS to a member (calls / texts / emails) and a token-bucket CONFIG (burst capacity + refill per hour), and DETERMINISTICALLY replays the attempts through the bucket to permit or throttle each — reporting the per-attempt decisions (with the token level seen just before each), the permitted / throttled tallies, the final token level, and the disposition: within-limits (none throttled) or throttled (some attempts exceeded the cap). The per-attempt decision is provably determined by the bucket state, and the exact throttle decision is the invariant this service reports and defends. It COMPLEMENTS, not duplicates, the Outreach Prioritization agent (which selects whom to reach): this caps how often one member may be reached. TIME IS DATA: the timestamps + config are plain numbers and the replay is a pure function of them (no real clock, no randomness), so the same request always yields the same determination. A throttle plan — within-limits / throttled — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresCoordinatorReview:true, autoSent:false); a throttled disposition is a LEGITIMATE FINDING (some attempts really exceed the cap), NOT a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.contactrate.replay-sourced (signal contactReplaySourced, violating value false) blocks a plan that isn't a real, self-consistent replay — the decisions must cover EXACTLY the submitted attempts (same ids, same timestamps, in non-decreasing time order — none dropped, added, reordered, or with a fabricated timestamp), the permitted / throttled tallies must match, attemptCount honest, and the disposition following — a fabricated attempt, a reordered replay, or a miscounted tally is a corrupted plan — the sourced + self-consistency gate (mirroring the Referral Throughput Agent's flow-sourced and the Batch Partition Agent's partition-sourced) — backed by the pure guard replaySourced; policy.contactrate.throttle-exact (signal contactThrottleExact, violating value false) blocks an over- or under-throttled decision — re-running the TOKEN-BUCKET simulation over the submitted attempts + config must reproduce the EXACT permit / throttle decision for every attempt and the final token level — this is the load-bearing correctness gate, and it re-simulates the bucket INDEPENDENT of the reported decisions (over-throttling denies a contact the bucket would allow; under-throttling permits a contact past the cap — over-contacting the member — so a fabricated replay that still reports the right tally fails sourced only, and a real-but-mis-simulated throttle fails exact only — the two gates are isolable) (mirroring the Referral Throughput Agent's throughput-optimal and the Care Routing Agent's route-optimal) — backed by the guard throttleExact; and policy.contactrate.no-autonomous-send (signal contactNoAutonomousSend, violating value false) blocks a determination that autonomously sent a permitted contact or suppressed a throttled one (autoSent:true — each is a member-communication action that must be authorized) or did not require coordinator review (requiresCoordinatorReview:false) — the agent PLANS on paper, and every plan is a RECOMMENDATION requiring an outreach coordinator to confirm — backed by the guard noAutonomousSend (mirroring the Referral Throughput Agent's no-autonomous-route and the Batch Partition Agent's no-autonomous-assign; the harmful action is enforced-off). It IS PHI-adjacent — the attempts reference member contacts — so it is on the HIPAA-audit policy (phiAccessed:true throughout) and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/contact-rate-limit/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — contactrate.receive-attempts → contactrate.throttle → contactrate.classify-disposition → contactrate.log-audit — with phiAccessed:true, returning the ContactRateLimitDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Contact Rate Limiting panel (a throttled preset over five attempts in 90 minutes against a capacity-3 bucket → 4 permitted / 1 throttled; a within-limits preset where hourly attempts match the refill; a dense capacity-1 burst → only the first permitted; plus reordered-replay / under-throttled / auto-sent governance-block presets), a seeded contactrate.receive-attempts→throttle→classify-disposition→log-audit trace showing the throttled case (permittedCount 4, requiresCoordinatorReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'one hundred three agents', with the Contact Rate Limiting agent on the care-coordination tier alongside the Outreach Prioritization agent) all reflect it. Menopause-relevant: a newly-enrolled member getting simultaneous nudges from the intake, care-gap, adherence, and education agents in the same afternoon is exactly the over-contact risk this token bucket caps — permitting a healthy cadence and throttling the rest — without ever sending a message on its own. Frontend tests green (+ contact-rate-limit simulateTokenBucket burst-refill / within / dense-burst / empty, evaluate throttled-within / sort-into-time-order / determinism, and three-guards-on-produced with reordered-replay + miscounted-tally + dropped-attempt + replay-sourced-vs-throttle-exact-isolation + under-throttled + mismatched-final-tokens + auto-sent + skipped-review guard cases, the route's envelope / three governance blocks / throttled + within + burst happy paths with a PHI-adjacent trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to one hundred three agents); the attempts are a clearly-labeled illustrative synthetic — NOT a certified communications-compliance system (real member-contact governance weighs TCPA / CAN-SPAM consent, quiet hours, channel-specific caps, member preferences, and campaign suppression lists — not a bare token bucket over illustrative timestamps). Lint + build clean.
Agent Fabric: added the Referral Throughput / Maximum-Flow Network Capacity (Edmonds–Karp) agent — deterministic max-flow / min-cut that computes the most referrals routable through a capacity network and names the bottleneck, with every plan a sourced conservation-consistent feasible flow, a recomputing maximum (max-flow = min-cut), and never an autonomous routing (the 102nd agent)
ShippedDetails
Added the one-hundred-and-second agent on the fabric — referral-throughput-agent, a DETERMINISTIC (no-Claude) care-coordination network-capacity agent on the PHI-adjacent patient/clinical plane, reusing the existing care-coordination tier as a SIBLING to the Network Build-Out, Care Routing, and Batch Partition agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY the heart of the service is MAXIMUM-FLOW / MINIMUM-CUT via EDMONDS–KARP (the BFS-augmenting-path refinement of FORD–FULKERSON): repeatedly find a shortest augmenting path from source to sink in the residual graph, push its bottleneck residual capacity, and update residual capacities (including back-edges) until no augmenting path remains; the total pushed is the maximum flow, and the source-reachable side of the final residual graph induces the minimum cut. It is NOT the Network Build-Out agent's MINIMUM SPANNING TREE (Kruskal's — connect all nodes at least cost; this pushes maximum flow through capacities), NOT the Care Routing agent's DIJKSTRA'S SHORTEST PATH (one cheapest path between two nodes; this saturates the whole network), and NOT the PCP Matching agent's GALE–SHAPLEY STABLE MATCHING, the Batch Partition agent's LINEAR PARTITION, the Outreach agent's 0/1 KNAPSACK, the Caseload Balancing agent's BIN-PACKING, the Household Composition agent's UNION-FIND, the SLA Worklist agent's EARLIEST-DEADLINE-FIRST SCHEDULING, or the Timeline Merge agent's K-WAY MERGE. In a new pure lib/referral-throughput.ts, evaluateReferralThroughput(request) takes a referral-routing NETWORK (a source feeding intake pools through capacity-limited specialty CHANNELS to a sink of appointment slots, each edge carrying a CAPACITY) and DETERMINISTICALLY computes the maximum flow (referrals routable end-to-end), reconstructs a feasible per-edge flow, and reads the min-cut off the final residual graph — reporting the flows, the max-flow value, the total demand (capacity leaving the source), the min-cut edges + capacity, and the disposition: unconstrained (throughput meets demand) or bottlenecked (a min-cut caps it below demand). By the max-flow min-cut theorem the maximum flow EQUALS the minimum cut capacity — the invariant this service reports and defends. It COMPLEMENTS, not duplicates, the sibling care-coordination agents: distinct from the Care Routing agent (cheapest single path) and the Network Build-Out agent (connect sites at least cost) — this pushes as much flow as possible through the capacities. TIME IS DATA: the capacities are plain numbers and the flow is a pure function of them (no real clock, no randomness — augmenting paths chosen by a deterministic BFS), so the same request always yields the same determination. A throughput plan — unconstrained / bottlenecked — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresCoordinatorReview:true, autoRouted:false); a bottlenecked disposition is a LEGITIMATE FINDING (a min-cut really caps throughput below demand), NOT a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.referralflow.flow-sourced (signal referralFlowSourced, violating value false) blocks a plan that isn't a real, feasible flow — every edge's flow must be between 0 and its SUBMITTED capacity (no fabricated edge, no over-capacity flow), flow CONSERVED at every non-source/sink node (in === out), the reported maxFlow the net out of source AND net into sink, nodeCount and edgeCount honest — a fabricated edge, an over-capacity flow, or a conservation violation is a corrupted plan — the sourced + self-consistency gate (mirroring the Network Build-Out Agent's tree-sourced and the Batch Partition Agent's partition-sourced) — backed by the pure guard flowSourced; policy.referralflow.throughput-optimal (signal referralThroughputOptimal, violating value false) blocks a sub-maximal or overstated throughput — re-running EDMONDS–KARP over the submitted network must reproduce the reported maxFlow, with the min-cut capacity equal to it — this is the load-bearing correctness gate, and it recomputes the maximum flow + min-cut INDEPENDENT of the reported per-edge flows (it compares the scalar optimum, not the assignment — different maximum flows achieve the same value — so a fabricated flow that still reports the optimal value fails sourced only, and a real-but-sub-maximal flow fails optimal only — the two gates are isolable) (mirroring the Network Build-Out Agent's cost-optimal and the Care Routing Agent's route-optimal) — backed by the guard throughputOptimal; and policy.referralflow.no-autonomous-route (signal referralNoAutonomousRoute, violating value false) blocks a determination that autonomously booked, dispatched, or routed a referral (autoRouted:true — each is a scheduling action that must be authorized) or did not require coordinator review (requiresCoordinatorReview:false) — the agent PLANS on paper, and every plan is a RECOMMENDATION requiring a referral coordinator to confirm — backed by the guard noAutonomousRoute (mirroring the Network Build-Out Agent's no-autonomous-provision and the Batch Partition Agent's no-autonomous-assign; the harmful action is enforced-off). It IS PHI-adjacent — the node labels reference intake pools / specialties / slots — so it is on the HIPAA-audit policy (phiAccessed:true throughout) and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/referral-throughput/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — referralflow.receive-network → referralflow.solve-maxflow → referralflow.classify-disposition → referralflow.log-audit — with phiAccessed:true, returning the ReferralThroughputDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Referral Throughput panel (a bottlenecked preset over a six-node menopause-clinic network → throughput 8 of 12 demanded, min-cut on the two specialty→slot edges; an unconstrained preset where throughput 3 meets demand 3; a diamond preset exercising residual back-edge cancellation → 3 of 4; plus over-capacity / sub-maximal / auto-routed governance-block presets), a seeded referralflow.receive-network→solve-maxflow→classify-disposition→log-audit trace showing the bottlenecked case (maxFlow 8, requiresCoordinatorReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'one hundred two agents', with the Referral Throughput agent on the care-coordination tier alongside the Care Routing and Network Build-Out agents) all reflect it. Menopause-relevant: sizing a menopause-clinic referral network — how many intake referrals can actually reach a gyn or endo appointment slot given each channel's weekly capacity, and which saturated edge to add capacity to — is exactly the max-flow / min-cut question this agent answers, without ever booking a referral on its own. Frontend tests green (+ referral-throughput maxFlowValue / minCut / reconstructFlows / evaluate bottlenecked-unconstrained-diamond / determinism / source-equals-sink, and three-guards-on-produced with over-capacity + conservation-violation + flow-sourced-vs-throughput-optimal-isolation + sub-maximal + overstated + auto-routed + skipped-review guard cases, the route's envelope / three governance blocks / bottlenecked + unconstrained + diamond happy paths with a PHI-adjacent trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to one hundred two agents); the capacities are a clearly-labeled illustrative synthetic — NOT a certified capacity-planning / scheduling system (real referral capacity planning weighs clinical urgency, specialty match, geography, payer networks, and provider preference — not a bare max-flow over illustrative capacities). Lint + build clean.
Agent Fabric: added the Provider Network Build-Out / Minimum Spanning Tree (Kruskal's Algorithm) agent — deterministic minimum spanning tree that connects a set of care sites into one network at minimum total build cost, with every plan sourced + self-consistent (a real acyclic subset of the candidate links), a recomputing minimal-cost optimum, and never an autonomous provisioning (the 101st agent)
ShippedDetails
Added the one-hundred-and-first agent on the fabric — network-buildout-agent, a DETERMINISTIC (no-Claude) care-coordination network-planning agent on the PHI-adjacent patient/clinical plane, reusing the existing care-coordination tier as a SIBLING to the Caseload Balancing, Batch Partition, SLA Worklist, and List Reconciliation agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY the heart of the service is MINIMUM SPANNING TREE construction via KRUSKAL'S ALGORITHM: sort the candidate links by ascending cost, then walk them cheapest-first, adding a link IFF it JOINS TWO DISTINCT COMPONENTS (a union-find cycle check rejects a link whose endpoints are already connected). Union-find here is a SUBROUTINE — the cycle test inside the greedy edge selection — NOT the computation itself: this is emphatically NOT the Household Composition agent's UNION-FIND CONNECTED-COMPONENT LABELING (which groups records into families by transitively merging match edges — NO edge weights, chooses NO minimum-cost subset, reports components not a tree). It is also DIFFERENT from the Care Routing agent's DIJKSTRA'S SHORTEST PATH (which minimizes the cost of ONE path between TWO nodes; MST minimizes the total cost to connect ALL nodes), the Batch Partition agent's LINEAR PARTITION, the Care Pathway agent's TOPOLOGICAL ORDERING, the Outreach agent's 0/1 KNAPSACK, the PCP Matching agent's GALE–SHAPLEY STABLE MATCHING, the SLA Worklist agent's EARLIEST-DEADLINE-FIRST SCHEDULING, the Huffman agent's OPTIMAL PREFIX CODING, the List Reconciliation agent's LONGEST COMMON SUBSEQUENCE, the Timeline Merge agent's K-WAY MERGE, and the Peak-Window agent's KADANE MAXIMUM-SUBARRAY. In a new pure lib/network-buildout.ts, evaluateNetworkBuildout(request) takes a set of care SITES (clinics / facilities / exchange endpoints) and candidate LINKS between them — each carrying a build COST — and DETERMINISTICALLY selects the MINIMUM-TOTAL-COST set of links that connects every site into ONE network, or reports a spanning FOREST when the candidate links cannot connect everything — reporting the chosen links, the minimum total build cost, the connected-component count, and the disposition: connected (componentCount === 1) or partitioned (more than one component remains). Kruskal's tree is provably optimal — no spanning tree of the candidate links has a smaller total cost — and the minimum total build cost is the invariant this service reports and defends. It COMPLEMENTS, not duplicates, the sibling care-coordination agents: distinct from the Care Routing agent (which finds the cheapest single path between two nodes) — this finds the cheapest way to connect ALL the sites. TIME IS DATA: the costs are plain numbers and the tree is a pure function of them (no real clock, no randomness — ties broken by a stable link ordering), so the same request always yields the same determination. A build plan — connected / partitioned — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresArchitectReview:true, autoProvisioned:false); a partitioned disposition is a LEGITIMATE FINDING (the candidate links really can't connect every site), NOT a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.netbuildout.tree-sourced (signal networkTreeSourced, violating value false) blocks a plan that isn't a real, self-consistent accounting of the submitted candidates — each chosen link must be a SUBMITTED candidate (same endpoints, same cost — no fabricated link, no altered cost), the chosen links must form a FOREST (no cycle, verified by a union-find pass over the chosen links), the reported totalCost equal to the sum of the chosen links' costs, the reported componentCount equal to the components the chosen links induce over the sites, siteCount and linkCount honest, and the disposition following — a fabricated link, an altered cost, or a cycle is a corrupted plan — the sourced + self-consistency gate (mirroring the Batch Partition Agent's partition-sourced and the Huffman Agent's code-sourced) — backed by the pure guard treeSourced; policy.netbuildout.cost-optimal (signal networkTreeCostOptimal, violating value false) blocks a sub-optimal tree that wastes build budget — re-running the KRUSKAL solver over the submitted sites + links must reproduce the reported totalCost (and disposition) — this is the load-bearing correctness gate, and it recomputes the minimum total cost from the sites + links INDEPENDENT of the reported tree (it compares the scalar optimum, not the tree — different minimum spanning trees can tie on cost — so a fabricated tree that still reports the optimal total cost fails sourced only, and a real-but-sub-optimal tree fails optimal only — the two gates are isolable) (mirroring the Batch Partition Agent's load-optimal and the Care Routing Agent's route-optimal) — backed by the guard treeOptimal; and policy.netbuildout.no-autonomous-provision (signal networkNoAutonomousProvision, violating value false) blocks a determination that autonomously provisioned, activated, or ordered a link (autoProvisioned:true — each is an infrastructure change that must be authorized) or did not require architect review (requiresArchitectReview:false) — the agent PLANS on paper, and every build plan is a RECOMMENDATION requiring a network architect to confirm — backed by the guard noAutonomousProvision (mirroring the Batch Partition Agent's no-autonomous-assign and the Huffman Agent's no-autonomous-deploy; the harmful action is enforced-off). It IS PHI-adjacent — the site labels reference clinics / facilities — so it is on the HIPAA-audit policy (phiAccessed:true throughout) and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/network-buildout/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — netbuildout.receive-network → netbuildout.build → netbuildout.classify-disposition → netbuildout.log-audit — with phiAccessed:true, returning the NetworkBuildoutDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Network Build-Out panel (a connected preset over five care sites + seven candidate links → minimum total build cost 18 across four links; a partitioned preset where a detached annex leaves two components; a triangle preset where the priciest link closes a cycle and is dropped → cost 3 not 10; plus fabricated-link / sub-optimal / auto-provisioned governance-block presets), a seeded netbuildout.receive-network→build→classify-disposition→log-audit trace showing the connected case (totalCost 18, requiresArchitectReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'one hundred one agents', with the Network Build-Out agent on the care-coordination tier alongside the Care Routing agent) all reflect it. Menopause-relevant: standing up a connected menopause-care network — linking a hub clinic, satellite offices, a lab, and a telehealth endpoint at the least total integration cost so records and referrals flow across all of them — is exactly the connect-everything-cheaply problem this minimum spanning tree solves, without ever provisioning a link on its own. Frontend tests green (+ network-buildout kruskalMST / cycle-drop / spanning-forest / unknown-site-and-self-loop / empty, connected / partitioned / triangle / determinism, and three-guards-on-produced with fabricated-link + dishonest-cost + cycle + tree-sourced-vs-cost-optimal-isolation + sub-optimal + auto-provisioned + skipped-review guard cases, the route's envelope / three governance blocks / connected + partitioned + triangle happy paths with a PHI-adjacent trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to one hundred one agents); the costs are a clearly-labeled illustrative synthetic — NOT a certified network-design system (real provider-network design weighs adequacy standards, contracted rates, capacity, redundancy, and regulatory requirements — not a bare minimum spanning tree over illustrative costs). Lint + build clean.
Agent Fabric: added the Chart Review Batch Partitioning / Linear Partition (Binary-Search-on-Answer) agent — deterministic linear partition that splits a priority-ordered clinical review worklist into k contiguous batches minimizing the busiest reviewer's load, with every partition sourced + self-consistent (a real order-preserving cover), a recomputing minimal-peak-load optimum, and never an autonomous reviewer assignment (the 100th agent)
ShippedDetails
Added the one-hundredth agent on the fabric — batch-partition-agent, a DETERMINISTIC (no-Claude) care-coordination workload-partitioning agent on the PHI-adjacent patient/clinical plane, reusing the existing care-coordination tier as a SIBLING to the Caseload Balancing, SLA Worklist, List Reconciliation, and Peak-Window agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY it is NOT the Caseload Balancing agent's WORST-FIT-DECREASING BIN-PACKING (which reorders members by descending acuity and greedily drops each into the emptiest bin — an UNORDERED heuristic assignment) and NOT the Peak-Window agent's KADANE MAXIMUM-SUBARRAY (which finds one best contiguous window, not a k-way split); it is also NOT the Huffman agent's OPTIMAL PREFIX CODING, the List Reconciliation agent's LONGEST COMMON SUBSEQUENCE, the SLA Worklist agent's EARLIEST-DEADLINE-FIRST SCHEDULING, the Care Routing agent's DIJKSTRA'S SHORTEST PATH, the Outreach agent's 0/1 KNAPSACK, the PCP Matching agent's GALE–SHAPLEY STABLE MATCHING, the Scheduling agent's INTERVAL SELECTION, or the Household Composition agent's UNION-FIND: the heart of the service is the LINEAR PARTITION PROBLEM solved by BINARY SEARCH ON THE ANSWER. In a new pure lib/batch-partition.ts, evaluateBatchPartition(request) takes a CHRONOLOGICALLY / PRIORITY-ORDERED clinical review worklist — each item carrying an effort WEIGHT (estimated review minutes / complexity points) — and a reviewer count k, and DETERMINISTICALLY splits it into k CONTIGUOUS batches (order preserved: no item jumps its neighbours) that MINIMIZE the busiest reviewer's load (the maximum batch weight): the minimal feasible peak load lies between the single heaviest item and the total weight; a greedy feasibility test (how many contiguous batches does a candidate cap require?) is monotonic in the cap, so binary search converges on the exact minimal maximum, and an order-preserving DP reconstructs the split — reporting the batch boundaries, each batch load, the minimal achievable peak load (maxBatchLoad), the heaviest single item, the total weight, and the disposition: divisible (the peak exceeds every single item) or item-bound (one dominant item sets the peak — more reviewers cannot lower it). The linear partition minimum is provably optimal — no contiguous k-way split achieves a smaller maximum — and the minimal peak load is the invariant this service reports and defends. Order matters — the split is CONTIGUOUS — which is exactly what unordered bin-packing throws away. It COMPLEMENTS, not duplicates, the sibling care-coordination agents: distinct from the Caseload Balancing agent (which greedily bin-packs unordered members into capacity-bounded panels) — this splits an ORDERED worklist into contiguous batches, provably minimizing the peak. TIME IS DATA: the weights are plain numbers and the partition is a pure function of them (no real clock, no randomness), so the same request always yields the same determination. A partition — divisible / item-bound — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresSupervisorReview:true, autoAssigned:false), which is how a legitimate partition is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.batchpartition.partition-sourced (signal batchPartitionSourced, violating value false) blocks a partition that isn't a real, self-consistent accounting of the submitted worklist — the batches, concatenated IN ORDER, must reproduce EXACTLY the submitted items (same labels, same weights, same sequence — no item dropped, added, reordered, or split across batches), there must be exactly batchCount NON-EMPTY contiguous batches, each batch's load equal to the sum of its items' weights, the reported maxBatchLoad the largest batch load, maxItemWeight and totalWeight honest, and the disposition following — a fabricated batch, a reordered cover, or an overstated load is a corrupted partition — the sourced + self-consistency gate (mirroring the Huffman Agent's code-sourced and the List Reconciliation Agent's diff-sourced) — backed by the pure guard partitionSourced; policy.batchpartition.load-optimal (signal batchPartitionLoadOptimal, violating value false) blocks a sub-optimal split that overloads one reviewer — re-running the LINEAR-PARTITION solver (binary search on the answer) over the submitted weights + batchCount must reproduce the reported maxBatchLoad (and disposition) — this is the load-bearing correctness gate, and it recomputes the minimal peak load from the weights INDEPENDENT of the reported batches (it compares the scalar optimum, not the cover — different optimal splits achieve the same minimal maximum — so a fabricated cover that still reports the optimal peak load fails sourced only, and a real-but-sub-optimal split fails optimal only — the two gates are isolable) (mirroring the Huffman Agent's code-optimal and the Care Routing Agent's route-optimal) — backed by the guard partitionOptimal; and policy.batchpartition.no-autonomous-assign (signal batchPartitionNoAutonomousAssign, violating value false) blocks a determination that autonomously assigned a named reviewer to a batch or dispatched the worklist (autoAssigned:true — each is a staffing action that must be authorized) or did not require supervisor review (requiresSupervisorReview:false) — the agent PARTITIONS on paper, and every partition is a RECOMMENDATION requiring a supervisor to confirm — backed by the guard noAutonomousAssign (mirroring the Huffman Agent's no-autonomous-deploy and the SLA Worklist Agent's no-autonomous-dispatch; the harmful action is enforced-off). It IS PHI-adjacent — the item labels reference charts / encounters — so it is on the HIPAA-audit policy (phiAccessed:true throughout) and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/batch-partition/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — batchpartition.receive-worklist → batchpartition.partition → batchpartition.classify-disposition → batchpartition.log-audit — with phiAccessed:true, returning the BatchPartitionDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Batch Partition panel (a divisible preset over a six-chart backlog split across three reviewers → minimal peak load 10, total 24; an item-bound preset where one 20-point chart sets the floor; an even preset with four equal-weight encounters split into two perfectly-balanced batches of 8; plus reordered-cover / sub-optimal / auto-assigned governance-block presets), a seeded batchpartition.receive-worklist→partition→classify-disposition→log-audit trace showing the divisible case (maxBatchLoad 10, requiresSupervisorReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'one hundred agents', with the Batch Partition agent on the care-coordination tier alongside the Caseload Balancing agent) all reflect it. Menopause-relevant: a menopause-clinic chart-review backlog — annual visit notes, HRT titration reviews, lab-result reconciliations — priority-ordered and split evenly across the reviewing clinicians so no one reviewer is overloaded, is exactly the ordered worklist this linear partition balances, without ever assigning a named reviewer on its own. Frontend tests green (+ batch-partition optimalMaxLoad / partitionItems / evaluate divisible-item-bound-even / determinism, and three-guards-on-produced with reordered-cover + dishonest-load + dropped-item + partition-sourced-vs-load-optimal-isolation + sub-optimal + auto-assigned + skipped-review guard cases, the route's envelope / three governance blocks / divisible + item-bound + even happy paths with a PHI-adjacent trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to one hundred agents); the weights are a clearly-labeled illustrative synthetic — NOT a certified staffing / workforce-management system (real reviewer scheduling weighs skills, certifications, shift rules, breaks, and fatigue — not a bare contiguous split by an effort number). Lint + build clean.
Agent Fabric: added the Event-Stream Code Assignment / Huffman Optimal Prefix Coding agent — deterministic Huffman coding that assigns an optimal prefix-free binary code to a stream of event types by frequency (minimizing the total encoded length), with every code sourced + self-consistent (a real, uniquely-decodable prefix code), a recomputing Huffman optimum, and never an autonomous codec deploy (the 99th agent)
ShippedDetails
Added the ninety-ninth agent on the fabric — huffman-coding-agent, a DETERMINISTIC (no-Claude) platform / data-plane code-assignment agent on the NON-PHI platform & data-substrate plane, reusing the existing data-plane tier as a SIBLING to the Code Taxonomy, Identifier Validation, Source Consensus, and Timeline Merge agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY it is NOT the Code Taxonomy agent's TRIE LONGEST-PREFIX MATCH (which walks a code down a prefix tree of taxonomy categories to bucket it — a lookup, not a code construction) and NOT the Identifier Validation agent's MODULAR-ARITHMETIC CHECKSUM; it is also NOT the Source Consensus agent's BOYER–MOORE MAJORITY VOTE, the Timeline Merge agent's K-WAY MERGE, the List Reconciliation agent's LONGEST COMMON SUBSEQUENCE, the SLA Worklist agent's EARLIEST-DEADLINE-FIRST SCHEDULING, the Peak-Window agent's KADANE MAXIMUM-SUBARRAY, the Care Routing agent's DIJKSTRA'S SHORTEST PATH, the Outreach agent's 0/1 KNAPSACK, the PCP Matching agent's GALE–SHAPLEY STABLE MATCHING, the Household Composition agent's UNION-FIND, the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS, or the MLR Rebate agent's LARGEST-REMAINDER APPORTIONMENT: the heart of the service is HUFFMAN CODING. In a new pure lib/huffman-coding.ts, evaluateHuffman(request) takes a set of event / message TYPES flowing across the integration bus — each type with an observed FREQUENCY (its share of the stream volume) — and DETERMINISTICALLY builds the optimal prefix-free code by repeatedly merging the two lowest-frequency nodes into a subtree (a greedy priority-queue construction, tie-broken by a stable creation-order counter), then reads each symbol's code off the root-to-leaf path — reporting one code per type, the weighted total encoded length (the sum over types of frequency × code length), the fixed-width baseline (ceil(log2(n)) bits per symbol × total frequency), and the disposition: compressible (the Huffman total beats the fixed-width baseline) or already-uniform (equal — a uniform distribution gains nothing). Huffman is provably optimal — no prefix-free code assigns a smaller total encoded length — and the total encoded length is the invariant this service reports and defends. It COMPLEMENTS, not duplicates, the sibling data-plane agents: distinct from the Code Taxonomy agent (which walks a code down a prefix tree of taxonomy categories to bucket it) and the Identifier Validation agent (which validates an identifier's check digit) — this CONSTRUCTS an optimal prefix-free code from frequencies. TIME IS DATA: the frequencies are plain numbers and the coding is a pure function of them (no real clock, no randomness), so the same request always yields the same determination. A code assignment — compressible / already-uniform — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresEngineerReview:true, autoDeployed:false), which is how a legitimate code is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.huffcode.code-sourced (signal huffCodeSourced, violating value false) blocks a code that isn't a real, self-consistent accounting of the submitted symbols — the reported codes must cover EXACTLY the submitted symbols (each once — no fabricated symbol, none dropped or double-coded), each code a non-empty binary string whose reported length matches, each frequency echoed, the code PREFIX-FREE (no code a prefix of another — the property that makes it uniquely decodable), the reported weightedTotal equal to Σ frequency × length, the fixed-width baseline computed honestly, and the disposition following — a fabricated symbol, a non-prefix-free code, or an overstated total is a corrupted assignment — the sourced + self-consistency gate (mirroring the List Reconciliation Agent's diff-sourced and the SLA Worklist Agent's schedule-sourced) — backed by the pure guard codeSourced; policy.huffcode.code-optimal (signal huffCodeOptimal, violating value false) blocks a sub-optimal prefix code that wastes bandwidth — re-running the HUFFMAN construction over the submitted frequencies must reproduce the reported weightedTotal (and disposition) — this is the load-bearing correctness gate, and it recomputes the minimal total encoded length from the frequencies INDEPENDENT of the reported codes (it compares the scalar optimum, not the code strings — different optimal trees achieve the same optimal length — so a fabricated non-prefix-free code that still reports the optimal length fails sourced only, and a real-but-sub-optimal code, e.g. a fixed-width code, fails optimal only — the two gates are isolable) (mirroring the List Reconciliation Agent's lcs-optimal and the Care Routing Agent's route-optimal) — backed by the guard codeOptimal; and policy.huffcode.no-autonomous-deploy (signal huffCodeNoAutonomousDeploy, violating value false) blocks a determination that autonomously deployed the codec to the live integration bus or re-encoded the production stream (autoDeployed:true — each is an infrastructure change that must be authorized) or did not require engineer review (requiresEngineerReview:false) — the agent ASSIGNS on paper, and every assignment is a RECOMMENDATION requiring an integration engineer to confirm — backed by the guard noAutonomousDeploy (mirroring the List Reconciliation Agent's no-autonomous-update and the SLA Worklist Agent's no-autonomous-dispatch; the harmful action is enforced-off). It operates ONLY on the platform / data-substrate plane — DELIBERATELY NOT PHI-bearing (phiAccessed:false throughout — an event-type frequency is aggregate integration telemetry, not patient health information), NOT on the HIPAA-audit policy, and NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/huffman-coding/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — huffcode.receive-symbols → huffcode.build-code → huffcode.classify-disposition → huffcode.log-audit — with phiAccessed:false, returning the HuffmanDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Huffman Coding panel (a compressible preset over five RPM device event types → 178 bits vs 300 fixed-width, 122 saved, the frequent 'heartbeat' getting a one-bit code; an already-uniform preset where four equally-frequent types match the 2-bit fixed-width code; a heavily-skewed ack/nack preset → 130 bits vs 200; plus non-prefix-free / sub-optimal / auto-deployed governance-block presets), a seeded huffcode.receive-symbols→build-code→classify-disposition→log-audit trace showing the compressible case (weightedTotal 178, requiresEngineerReview:true, phiAccessed:false), the console subtitle, and the investor brief (now 'ninety-nine agents', with the Huffman Coding agent on the data-plane tier alongside the Code Taxonomy agent) all reflect it. Menopause-relevant: a Pause remote-patient-monitoring device stream — heartbeat, normal readings, high readings, battery-low, sync-error — is exactly the skewed event stream this Huffman coder assigns compact codes to for efficient transmission across the integration bus, without ever deploying the codec on its own. Frontend tests green (4,188 tests — + huffman-coding Huffman-tree / single-symbol-one-bit / empty / fixed-width-baseline / optimal-length, compressible / already-uniform / heavily-skewed / determinism, and three-guards-on-produced with non-prefix-free + fabricated-symbol + overstated-total + code-sourced-vs-code-optimal-isolation + sub-optimal-fixed-width + auto-deployed + skipped-review guard cases, the route's envelope / three governance blocks / compressible + uniform + skewed happy paths with a non-PHI trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to ninety-nine agents); the frequencies are a clearly-labeled illustrative synthetic — NOT a certified codec / compression system (real stream compression uses context modeling, arithmetic / range coding, dictionary methods (LZ77 / LZMA), and adaptive codebooks). Lint + build clean.
Agent Fabric: added the Clinical List Reconciliation / Longest-Common-Subsequence (LCS) Diff agent — deterministic LCS reconciliation that diffs two ordered clinical lists (a prior list vs the current list), finds the items preserved in both (retained), and derives the added + removed items (lists-match / changes-present), with every diff sourced + self-consistent, a recomputing LCS optimum, and never an autonomous chart write (the 98th agent)
ShippedDetails
Added the ninety-eighth agent on the fabric — list-reconciliation-agent, a DETERMINISTIC (no-Claude) care-coordination reconciliation agent on the PHI-bearing patient/clinical plane, reusing the existing care-coordination tier as a SIBLING to the Medication Name Safety, Care Pathway, Transitions of Care, Care Routing, and Timeline Merge agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY it is NOT the Medication Name Safety agent's LEVENSHTEIN EDIT DISTANCE (which measures CHARACTER-level edit distance between two drug-name STRINGS to catch look-alike/sound-alike confusability) and NOT the Enrollment Reconciliation agent's KEYED SET RECONCILIATION (which joins two record sets on a key to find adds/drops/mismatches, order-independent); it is also NOT the Timeline Merge agent's K-WAY MERGE, the SLA Worklist agent's EARLIEST-DEADLINE-FIRST SCHEDULING, the Peak-Window agent's KADANE MAXIMUM-SUBARRAY, the Care Routing agent's DIJKSTRA'S SHORTEST PATH, the Outreach agent's 0/1 KNAPSACK, the Source Consensus agent's BOYER–MOORE MAJORITY VOTE, the Code Taxonomy agent's TRIE LONGEST-PREFIX MATCH, the Household Composition agent's UNION-FIND, the Care Pathway agent's TOPOLOGICAL ORDERING, or the Identifier Validation agent's MODULAR-ARITHMETIC CHECKSUM: the heart of the service is the LONGEST COMMON SUBSEQUENCE. In a new pure lib/list-reconciliation.ts, evaluateListReconciliation(request) takes TWO ordered clinical lists for one record — a PRIOR list (the medication list at admission, the problem list at last visit, the care-plan steps as last agreed) and a CURRENT list (the same list now) — and DETERMINISTICALLY runs a dynamic-programming table over the two ORDERED lists to find the longest subsequence common to both (the items kept, in their shared order — the RETAINED items), then complements it in each list to derive what was REMOVED (prior only) and ADDED (current only), reporting the retained / added / removed items, the LCS length, and the disposition: lists-match or changes-present. Order matters — LCS respects the sequence — which is exactly what set reconciliation throws away. It COMPLEMENTS, not duplicates, the sibling agents: distinct from the Medication Name Safety agent (which measures character-level edit distance between two drug-name strings) and the Enrollment Reconciliation agent (which joins two record sets on a key, order-independent) — this DIFFS two ORDERED lists respecting sequence. TIME IS DATA: the two lists are plain ordered tokens and the diff is a pure function of them (no real clock, no randomness), so the same request always yields the same determination. A reconciliation — lists-match / changes-present — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresClinicianReview:true, autoApplied:false), which is how a legitimate diff is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.listdiff.diff-sourced (signal listDiffSourced, violating value false) blocks a diff that isn't a real, self-consistent accounting of the two submitted lists — the reported RETAINED list must be a genuine COMMON SUBSEQUENCE of both lists (it appears in order within prior AND within current — nothing fabricated, nothing reordered), the REMOVED list must equal exactly the prior items left unmatched (in order), the ADDED list must equal exactly the current items left unmatched (in order), the reported lcsLength must match the retained length, and the disposition must follow — a fabricated / reordered retained item or a mis-stated add/remove is a corrupted diff — the sourced + self-consistency gate (mirroring the SLA Worklist Agent's schedule-sourced and the Peak-Window Agent's window-sourced) — backed by the pure guard diffSourced; policy.listdiff.lcs-optimal (signal listDiffLcsOptimal, violating value false) blocks a shorter-than-optimal common subsequence that over-reports change — re-running the LCS dynamic program over the two submitted lists must reproduce the reported lcsLength (and disposition) — this is the load-bearing correctness gate, and it recomputes the LCS length from the two lists INDEPENDENT of the reported retained subsequence (it compares the scalar optimum, not the reported items, so a fabricated retained list that still reports the optimal length fails sourced only, and a real-but-sub-optimal subsequence fails optimal only — the two gates are isolable) (mirroring the SLA Worklist Agent's edf-ordered and the Care Routing Agent's route-optimal) — backed by the guard diffOptimal; and policy.listdiff.no-autonomous-update (signal listDiffNoAutonomousUpdate, violating value false) blocks a determination that autonomously wrote the reconciled list back, updated the chart, or started/stopped a medication (autoApplied:true — each is a clinical write that must be authorized) or did not require clinician review (requiresClinicianReview:false) — the agent RECONCILES on paper, and every reconciliation is a RECOMMENDATION requiring a clinician to confirm — backed by the guard noAutonomousUpdate (mirroring the SLA Worklist Agent's no-autonomous-dispatch and the Resource Scheduling Agent's no-autonomous-booking; the harmful action is enforced-off). It IS PHI-bearing — the lists are one patient's clinical record — so it is on the HIPAA-audit policy (phiAccessed:true throughout) and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/list-reconciliation/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — listdiff.receive-lists → listdiff.diff-lcs → listdiff.classify-disposition → listdiff.log-audit — with phiAccessed:true, returning the ListReconciliationDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new List Reconciliation panel (a medication-list preset where admission→discharge retains metformin → atorvastatin → aspirin, removes lisinopril, and adds estradiol; a lists-match preset; a problem-list preset with several changes; plus fabricated-retained / sub-optimal / auto-applied governance-block presets), a seeded listdiff.receive-lists→diff-lcs→classify-disposition→log-audit trace showing the changes-present case (LCS length 3, requiresClinicianReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'ninety-eight agents', with the List Reconciliation agent on the care-coordination tier alongside the Medication Name Safety and Timeline Merge agents) all reflect it. Menopause-relevant: reconciling a menopause patient's medication list between admission and discharge — surfacing that lisinopril was stopped and estradiol started while metformin, atorvastatin, and aspirin were preserved — is exactly the retained/added/removed diff this LCS reconciler produces for a clinician to confirm, without ever writing the chart on its own. Frontend tests green (4,149 tests — + list-reconciliation LCS / lcsLength / identical-lists / no-common-item / empty, changed-medication-list / lists-match / problem-list / determinism, and three-guards-on-produced with fabricated-reordered-retained + mis-stated-add-remove + lcsLength-mismatch + diff-sourced-vs-lcs-optimal-isolation + sub-optimal + auto-applied + skipped-review guard cases, the route's envelope / three governance blocks / changed + lists-match + problem-list happy paths with a PHI trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to ninety-eight agents); the lists are a clearly-labeled illustrative synthetic — NOT a certified medication-reconciliation system (real medication / problem-list reconciliation normalizes to RxNorm / SNOMED and accounts for dose, route, frequency, therapeutic equivalence, and clinical intent). Lint + build clean.
Agent Fabric: added the SLA Worklist Sequencing / Earliest-Deadline-First (EDF) Scheduling agent — deterministic EDF scheduling that orders a worklist of pending cases by SLA deadline, computes each case's cumulative completion time, and flags the SLA breaches (all-on-time / breaches-present), with every schedule sourced + self-consistent, a recomputing EDF order, and never an autonomous dispatch (the 97th agent)
ShippedDetails
Added the ninety-seventh agent on the fabric — sla-worklist-agent, a DETERMINISTIC (no-Claude) payer-operations work-sequencing agent on the PHI-bearing payer & plan-operations plane, reusing the existing payer-operations tier as a SIBLING to the Claims Adjudication, Utilization Review, Coordination of Benefits, FWA Detection, and Formulary agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY it is NOT the Resource Scheduling agent's WEIGHTED INTERVAL SCHEDULING (which SELECTS a max-weight non-overlapping SUBSET of time-windowed requests for one resource — a subset, with dropped requests) and NOT the Scheduling Conflict agent's GREEDY INTERVAL SELECTION (which admits the max COUNT of non-overlapping appointments); it is also NOT the Peak-Window agent's KADANE MAXIMUM-SUBARRAY, the Care Routing agent's DIJKSTRA'S SHORTEST PATH, the Outreach agent's 0/1 KNAPSACK, the Source Consensus agent's BOYER–MOORE MAJORITY VOTE, the Code Taxonomy agent's TRIE LONGEST-PREFIX MATCH, the Timeline Merge agent's K-WAY MERGE, the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS, the Household Composition agent's UNION-FIND, the MLR Rebate agent's LARGEST-REMAINDER APPORTIONMENT, or the Identifier Validation agent's MODULAR-ARITHMETIC CHECKSUM: the heart of the service is EARLIEST-DEADLINE-FIRST (EDF) SCHEDULING. In a new pure lib/sla-worklist.ts, evaluateWorklist(request) takes a single WORKLIST of pending cases for one processor (a UM nurse's queue, an appeals analyst's desk, a claims-review bench) — each case a unit of work with a processing DURATION and an SLA DEADLINE — and DETERMINISTICALLY orders the entire worklist by deadline ascending (documented tie-break: earlier deadline first, then lexical case id), then processes the cases sequentially from time zero — each case starts when the previous finishes, its completion time is the running cumulative duration, and it BREACHES when its completion time exceeds its deadline — reporting the ordered worklist, the per-case completion times + lateness, the breach count, and the disposition: all-on-time or breaches-present. EDF is the classic optimal single-processor discipline: if ANY ordering can meet every deadline, EDF does (it minimizes the maximum lateness). It COMPLEMENTS, not duplicates, the sibling scheduling agents: distinct from the Resource Scheduling agent (which selects a max-value non-overlapping subset for one resource) and the Caseload Balancing agent (which bin-packs patients across care managers) — this ORDERS a whole worklist for one processor by SLA deadline and flags the breaches. TIME IS DATA: durations + deadlines are plain numbers (minutes from the top of the shift) and the sequencing is a pure function of the tasks (no real clock, no randomness), so the same worklist always yields the same schedule. A worklist — all-on-time / breaches-present — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresReviewerReview:true, autoDispatched:false), which is how a legitimate schedule is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.worklist.schedule-sourced (signal worklistScheduleSourced, violating value false) blocks a schedule that isn't a real, self-consistent accounting of the submitted cases — the scheduled list must be a PERMUTATION of the submitted tasks (each submitted case once — no fabricated case, none dropped or double-worked), each entry must echo its case's duration + deadline, the completion times must chain (the first starts at zero, each starts when the previous finishes, each completion = start + duration), each late flag must equal completion > deadline, the counts must add up, and the disposition must follow — the sourced + self-consistency gate (mirroring the Resource Scheduling Agent's selection-sourced and the Scheduling Conflict Agent's intervals-sourced) — backed by the pure guard scheduleSourced; policy.worklist.edf-ordered (signal worklistEdfOrdered, violating value false) blocks a non-EDF order that needlessly breaches deadlines — re-running the EARLIEST-DEADLINE-FIRST discipline over the submitted cases must reproduce the reported ORDER (cases sequenced by deadline ascending, tie-break by case id) — this is the load-bearing correctness gate, and it compares the ORDERING of the real submitted cases INDEPENDENT of the reported completion times (it extracts the subsequence of reported cases that are real submitted cases and verifies that subsequence is in EDF order, so a fabricated-case schedule that still orders the real cases correctly fails sourced only — the phantom is filtered out here — and a real-but-mis-ordered schedule fails ordered only — the two gates are isolable) (mirroring the Resource Scheduling Agent's schedule-optimal and the Care Routing Agent's route-optimal) — backed by the guard scheduleOrdered; and policy.worklist.no-autonomous-dispatch (signal worklistNoAutonomousDispatch, violating value false) blocks a determination that autonomously dispatched, started, or reassigned a case (autoDispatched:true — each is a work-assignment action that must be authorized) or did not require reviewer review (requiresReviewerReview:false) — the agent SEQUENCES on paper, and every worklist is a RECOMMENDATION requiring a supervisor to confirm — backed by the guard noAutonomousDispatch (mirroring the Resource Scheduling Agent's no-autonomous-booking and the Caseload Balancing Agent's no-autonomous-assignment; the harmful action is enforced-off). It IS PHI-bearing — each case references the member / claim being worked — so it is on the HIPAA-audit policy (phiAccessed:true throughout) and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/sla-worklist/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — worklist.receive-cases → worklist.sequence-edf → worklist.classify-disposition → worklist.log-audit — with phiAccessed:true, returning the WorklistDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new SLA Worklist panel (a with-breach preset over four UM authorization cases → EDF orders auth-502 → auth-501 → auth-504 → auth-503 with auth-504 breaching its 70-minute SLA; an all-on-time preset; an over-committed preset where even the optimal EDF order breaches two SLAs; plus fabricated-case / non-EDF-order / auto-dispatched governance-block presets), a seeded worklist.receive-cases→sequence-edf→classify-disposition→log-audit trace showing the breaches-present case (1 of 4 breaching, requiresReviewerReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'ninety-seven agents', with the SLA Worklist agent on the payer-operations tier alongside the Utilization Review and Coordination of Benefits agents) all reflect it. Menopause-relevant: a UM / appeals queue of menopause-care prior-auths and appeals racing regulatory SLA clocks is exactly the worklist this EDF sequencer orders to minimize breaches — surfacing an over-committed queue to a supervisor rather than silently missing deadlines, and never dispatching the work on its own. Frontend tests green (4,110 tests — + sla-worklist EDF order-and-chain / deadline-tie-break / empty, breaches / all-on-time / over-committed / determinism, and three-guards-on-produced with fabricated-case + mis-chained-completion + count-mismatch + schedule-sourced-vs-edf-ordered-isolation + non-EDF-order + auto-dispatched + skipped-review guard cases, the route's envelope / three governance blocks / breaches + all-on-time + over-committed happy paths with a PHI trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to ninety-seven agents); the worklist is a clearly-labeled illustrative synthetic — NOT a certified workforce / queueing system (real worklist management uses staffing levels, skills-based routing, case arrival times, preemption, priority tiers, and shift schedules). Lint + build clean.
Agent Fabric: added the Commercial Peak-Window / Maximum Contiguous Net-Gain Detection agent — deterministic Kadane's maximum-subarray that finds the single maximum-sum contiguous window (the peak net-gain stretch) in a signed metric series (positive-window / no-positive-window), with every window sourced + self-honest, a recomputing Kadane optimum, and never an autonomous action (the 96th agent)
ShippedDetails
Added the ninety-sixth agent on the fabric — peak-window-agent, a DETERMINISTIC (no-Claude) commercial-analytics agent on the strictly PHI-separated commercial CRM plane, reusing the existing commercial-operations tier as a SIBLING to the KPI Trend, Pipeline Management, Account Management, Provider Contracting, Provider Benchmarking, and Deal Desk agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY it is NOT the sibling KPI Trend agent's ORDINARY LEAST-SQUARES LINEAR REGRESSION (which fits a best-fit line and PROJECTS it to a horizon — a fitted model + extrapolation), NOT the Quality Shift agent's CUSUM CHANGE-POINT DETECTION (a running deviation from a target to catch a SUSTAINED shift), NOT the Access Anomaly agent's SLIDING-WINDOW COUNTING (a FIXED-width window sliding over events), and NOT the Remote Patient Monitoring agent's WINDOW-VS-BASELINE trend classification; it is also NOT the Resource Scheduling agent's WEIGHTED INTERVAL SCHEDULING, the Care Routing agent's DIJKSTRA'S SHORTEST PATH, the Outreach agent's 0/1 KNAPSACK, the Source Consensus agent's BOYER–MOORE MAJORITY VOTE, the Code Taxonomy agent's TRIE LONGEST-PREFIX MATCH, the Timeline Merge agent's K-WAY MERGE, the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS, the Household Composition agent's UNION-FIND, or the Identifier Validation agent's MODULAR-ARITHMETIC CHECKSUM: the heart of the service is KADANE'S MAXIMUM-SUBARRAY. In a new pure lib/peak-window.ts, evaluatePeakWindow(request) takes a time-ordered series of a business metric's SIGNED per-period NET CHANGE (net-new ARR = bookings − churn, net enrolled patients = adds − drops, net revenue delta) and DETERMINISTICALLY runs a single linear scan carrying a running sum that RESETS whenever extending the previous stretch would do worse than starting fresh at the current period (curSum = max(x_i, curSum + x_i)), tracking the best window seen — the maximum-sum contiguous subarray in O(n) — to find the single MAXIMUM-SUM CONTIGUOUS WINDOW (the strongest sustained net-gain STRETCH), reporting its start / end period, summed net gain, and length, or honestly reporting NO POSITIVE WINDOW when every contiguous stretch nets a loss (returning the least-negative single period), and deriving the disposition: positive-window or no-positive-window. A fixed-width or whole-series average hides the true peak run; Kadane finds the exact contiguous window that maximizes net gain. It COMPLEMENTS, not duplicates, the sibling commercial agents: distinct from the KPI Trend agent (which fits a least-squares trend line and projects it) and the Pipeline Management agent (which rolls up CRM opportunity records) — this finds the peak contiguous net-gain window. TIME IS DATA: the series is plain labeled numbers and the detection is a pure function of the series (no real clock, no randomness), so the same request always yields the same determination. A window — positive-window / no-positive-window — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresAnalystReview:true, autoActioned:false), which is how a legitimate window is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.peak-window.window-sourced (signal peakWindowSourced, violating value false) blocks a window that isn't a real, self-honest sub-range of the submitted series — the reported window must be a REAL contiguous sub-range (0 <= startIndex <= endIndex < n), its reported windowLength must match (end − start + 1), its reported windowSum must equal the ACTUAL sum of the series over that range, and hasPositiveWindow / disposition must follow the sum's sign — a window that runs off the series or overstates its own sum is a fabricated finding — the sourced + self-honesty gate (mirroring the Care Routing Agent's path-sourced and the Resource Scheduling Agent's selection-sourced) — backed by the pure guard windowSourced; policy.peak-window.window-optimal (signal peakWindowOptimal, violating value false) blocks a sub-optimal window that under-reports the true peak run — re-running Kadane's maximum-subarray over the submitted series must reproduce the reported windowSum and the same positive-window / no-positive-window disposition — this is the load-bearing correctness gate, and it recomputes the optimum from the series INDEPENDENT of the reported window bounds (it recomputes the max sum, not the reported window, so a fabricated out-of-range window that still reports the optimal sum fails sourced only, and a real-but-sub-optimal window fails optimal only — the two gates are isolable) (mirroring the Care Routing Agent's route-optimal and the Resource Scheduling Agent's schedule-optimal) — backed by the guard windowOptimal; and policy.peak-window.no-autonomous-action (signal peakWindowNoAutonomousAction, violating value false) blocks a determination that autonomously committed the finding as an official metric, adjusted a quota / target, or notified finance (autoActioned:true — each is a consequential commercial action that must be authorized) or did not require analyst review (requiresAnalystReview:false) — the agent DETECTS on paper, and every window is a RECOMMENDATION requiring a revenue analyst to confirm — backed by the guard noAutonomousAction (mirroring the KPI Trend Agent's no-autonomous-commit and the Provider Benchmarking Agent's no-autonomous-tiering; the harmful action is enforced-off). It operates ONLY on the commercial CRM plane — DELIBERATELY NOT PHI-bearing (phiAccessed:false throughout), NOT on the HIPAA-audit policy, and NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/peak-window/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — peak.receive-series → peak.scan-max-subarray → peak.classify-disposition → peak.log-audit — with phiAccessed:false, returning the PeakWindowDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Peak Window panel (a positive-window preset over twelve months of net-new ARR → the Apr→Aug peak run netting +58; a no-positive-window preset; a whole-series-is-the-window preset; plus fabricated-window / sub-optimal / auto-actioned governance-block presets), a seeded peak.receive-series→scan-max-subarray→classify-disposition→log-audit trace showing the positive-window case (window sum 58 over 5 periods, requiresAnalystReview:true, phiAccessed:false), the console subtitle, and the investor brief (now 'ninety-six agents', with the Peak Window agent on the commercial-operations tier alongside the KPI Trend agent) all reflect it. Menopause-relevant: the strongest contiguous growth stretch in Pause's net-new enrolled-patient or net-new-ARR series is exactly the momentum window this agent surfaces for a GTM review — without ever committing the figure or moving a quota on its own. Frontend tests green (4,073 tests — + peak-window Kadane max-subarray / all-negative-least-negative / all-positive-whole-series / earliest-window-on-tie / empty, positive-window / no-positive-window / whole-series / determinism, and three-guards-on-produced with out-of-range-fabricated + overstated-sum + length-mismatch + window-sourced-vs-window-optimal-isolation + sub-optimal + auto-actioned + skipped-review guard cases, the route's envelope / three governance blocks / positive + no-positive + whole-series happy paths with a non-PHI trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to ninety-six agents); the series are clearly-labeled illustrative aggregate business figures — NOT a certified analytics / FP&A system (real commercial analytics weighs seasonality, cohort dynamics, pipeline mix, macro conditions, and human judgment). Lint + build clean.
Agent Fabric: added the Resource-Block Scheduling / Max-Value Non-Overlapping Selection agent — deterministic weighted interval scheduling (dynamic programming) that selects the max-total-weight non-overlapping set of competing requests for one contended resource (all-scheduled / contended), with every selection sourced + feasible, a recomputing DP optimum, and never an autonomous booking (the 95th agent)
ShippedDetails
Added the ninety-fifth agent on the fabric — resource-scheduling-agent, a DETERMINISTIC (no-Claude) care-coordination capacity-optimization service on the patient & clinical-operations plane, reusing the existing care-coordination tier as a SIBLING to the Scheduling Conflict, Caseload Balancing, and Appointment Scheduling agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric, and CRUCIALLY it is NOT the sibling Scheduling Conflict agent's GREEDY INTERVAL SELECTION (which maximizes the COUNT of double-booking-free appointments, WEIGHTLESS) and NOT the Caseload Balancing agent's GREEDY BIN-PACKING under a capacity constraint or the Outreach Prioritization agent's 0/1 KNAPSACK DYNAMIC PROGRAMMING (items with a value + a cost packed under a single capacity budget, no time / overlap structure); it is also NOT the Care Routing agent's DIJKSTRA'S WEIGHTED SHORTEST PATH, the Source Consensus agent's BOYER–MOORE MAJORITY VOTE, the Code Taxonomy agent's TRIE LONGEST-PREFIX MATCH, the KPI Trend agent's LEAST-SQUARES REGRESSION, the Quality Shift agent's CUSUM CHANGE-POINT DETECTION, the Timeline Merge agent's K-WAY MERGE, the PCP Matching agent's STABLE MATCHING, the Network Adequacy agent's GREAT-CIRCLE DISTANCE, the Household Composition agent's UNION-FIND, the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS, or the Identifier Validation agent's MODULAR-ARITHMETIC CHECKSUM: the heart of the service is WEIGHTED INTERVAL SCHEDULING via DYNAMIC PROGRAMMING. In a new pure lib/resource-scheduling.ts, evaluateBlockSchedule(request) takes a single SHARED SCARCE RESOURCE (an infusion chair, an OR block, a specialist's slot ladder, an imaging machine) and a batch of competing REQUESTS for it — each a half-open [start, end) time WINDOW with a priority WEIGHT (clinical value / acuity) — and DETERMINISTICALLY sorts the requests by end time, computes for each request i the latest earlier request p(i) that does NOT overlap it, fills dp[i] = max(dp[i-1], weight_i + dp[p(i)]), and backtracks to recover the MAX-WEIGHT compatible subset — selecting the maximum-total-weight set of non-overlapping requests the resource can honor, reporting the rest as CONTENDED, and deriving the disposition: all-scheduled or contended. A greedy earliest-finish rule maximizes the COUNT of appointments but can leave clinical VALUE on the table (two short low-acuity blocks beat one long high-acuity block by count, but not by weight); the DP maximizes the total weight the resource actually delivers. It COMPLEMENTS, not duplicates, the sibling scheduling agents: distinct from the Scheduling Conflict agent (which maximizes the COUNT of double-booking-free appointments) and the Caseload Balancing agent (which bin-packs patients across care managers) — this picks the max-VALUE non-overlapping set for one contended resource. TIME IS DATA: the windows are plain numbers (epoch-minutes / slot indices) and the selection is a pure function of the requests (no real clock, no randomness), so the same request always yields the same determination. A schedule — all-scheduled / contended — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresSchedulerReview:true, autoBooked:false), which is how a legitimate schedule is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.block-schedule.selection-sourced (signal blockScheduleSourced, violating value false) blocks a selection that isn't a real, feasible subset of the submitted requests — every selected id must be a SUBMITTED request (no fabricated block, none double-counted), the selected windows must be pairwise NON-OVERLAPPING (the resource is never double-booked), the reported totalWeight must equal the sum of the selected weights, the counts must add up (scheduled + contended = total = requests), and the disposition must follow — the sourced + feasibility gate (mirroring the Scheduling Conflict Agent's intervals-sourced + conflict-free and the Care Routing Agent's path-sourced) — backed by the pure guard selectionSourced; policy.block-schedule.schedule-optimal (signal blockScheduleOptimal, violating value false) blocks a sub-optimal schedule that silently leaves clinical value unbooked — re-running the weighted-interval DP over the submitted requests must reproduce the reported totalWeight and the same all-scheduled / contended disposition — this is the load-bearing correctness gate, and it recomputes the optimum from the requests INDEPENDENT of the reported selection (it recomputes the max weight, not the reported selected set, so a fabricated-block selection that still reports the optimal total fails sourced only, and a real-but-sub-optimal selection fails optimal only — the two gates are isolable) (mirroring the Care Routing Agent's route-optimal and the Outreach Prioritization Agent's selection-optimal) — backed by the guard selectionOptimal; and policy.block-schedule.no-autonomous-booking (signal blockScheduleNoAutonomousBooking, violating value false) blocks a determination that autonomously booked, bumped, or confirmed a block (autoBooked:true — each is a scheduling action that must be authorized) or did not require scheduler review (requiresSchedulerReview:false) — the agent SELECTS on paper, and every schedule is a RECOMMENDATION requiring a scheduler to confirm — backed by the guard noAutonomousBooking (mirroring the Scheduling Conflict Agent's no-autonomous-booking and the Caseload Balancing Agent's no-autonomous-assignment; the harmful action is enforced-off). It IS PHI-bearing — each request references the patient being scheduled — so it is on the HIPAA-audit policy (phiAccessed:true throughout) and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/resource-scheduling/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — schedule.receive-requests → schedule.optimize-selection → schedule.classify-disposition → schedule.log-audit — with phiAccessed:true, returning the BlockScheduleDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Resource Scheduling panel (a contended infusion-chair preset → the max-weight subset {infusion-1101, infusion-1104} = weight 11; an all-scheduled preset; a weight-beats-count preset where the DP takes one weight-10 block over two weight-3 blocks; plus fabricated-block / sub-optimal / auto-booked governance-block presets), a seeded schedule.receive-requests→optimize-selection→classify-disposition→log-audit trace showing the contended case (2 of 5 scheduled, total weight 11, requiresSchedulerReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'ninety-five agents', with the Resource Scheduling agent on the care-coordination tier alongside the Scheduling Conflict and Caseload Balancing agents) all reflect it. Menopause-relevant: a menopause-care program competing for a scarce infusion chair, an imaging slot, or a specialist block against higher- and lower-acuity requests is exactly the contention this DP resolves by delivered clinical value — without ever booking the block on its own. Frontend tests green (4,034 tests — + resource-scheduling weighted-interval max-weight-subset / weight-over-count / all-non-overlapping / empty, contended / all-scheduled / determinism, and three-guards-on-produced with fabricated-block + double-booked + totalWeight-mismatch + count-mismatch + selection-sourced-vs-schedule-optimal-isolation + sub-optimal + auto-booked + skipped-review guard cases, the route's envelope / three governance blocks / contended + all-scheduled + weight-over-count happy paths with a PHI trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to ninety-five agents); the resource + requests are clearly-labeled illustrative synthetics — NOT a certified scheduling / capacity system (real resource scheduling uses provider availability calendars, appointment-type durations, buffer / turnover times, room / equipment constraints, and staffing ratios). Lint + build clean.
Agent Fabric: added the Clinical Code Taxonomy / Longest-Prefix Classification agent — deterministic trie (prefix tree) longest-prefix match that classifies a batch of clinical codes to their most-specific taxonomy category (all-classified / unclassified-present), with every classification sourced, a recomputing match, and never an autonomous re-code (the 94th agent)
ShippedDetails
Added the ninety-fourth agent on the fabric — code-taxonomy-agent, a DETERMINISTIC (no-Claude) data-substrate terminology / value-set service on the platform & data-substrate plane, reusing the existing data-plane tier as a SIBLING to the Identifier Validation, Source Consensus, Master-Patient-Index, and Timeline Merge agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: it is NOT the Source Consensus agent's BOYER–MOORE MAJORITY VOTE, the Care Routing agent's DIJKSTRA'S WEIGHTED SHORTEST PATH, the KPI Trend agent's LEAST-SQUARES LINEAR REGRESSION, the Outreach Prioritization agent's 0/1 KNAPSACK DYNAMIC PROGRAMMING, the Quality Shift agent's CUSUM CHANGE-POINT DETECTION, the Timeline Merge agent's K-WAY MERGE OF SORTED STREAMS, the Reportable Condition agent's RECURSIVE BOOLEAN EXPRESSION-TREE EVALUATION, the PCP Matching agent's TWO-SIDED STABLE MATCHING (Gale–Shapley), the Network Adequacy agent's GEOSPATIAL GREAT-CIRCLE DISTANCE, the Household Composition agent's UNION-FIND CONNECTED COMPONENTS, the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS, the MLR Rebate agent's LARGEST-REMAINDER APPORTIONMENT, the Schedule Conflict agent's GREEDY INTERVAL SELECTION, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, the Audit Log Integrity agent's HASH CHAIN, or the Claim Lifecycle agent's BFS REACHABILITY, and — CRUCIALLY — it is NOT the Identifier Validation agent's MODULAR-ARITHMETIC CHECKSUM (character math on a single identifier's Luhn check digit), the Medication Name Safety agent's STRING EDIT DISTANCE (how far apart two drug NAMES are), or the HCC Risk Adjustment agent's HIERARCHY + COEFFICIENT SUM (rolling confirmed conditions up a clinical hierarchy and summing RAF coefficients): the heart of the service is a TRIE (PREFIX TREE) LONGEST-PREFIX MATCH. In a new pure lib/code-taxonomy.ts, evaluateCodeTaxonomy(request) takes a BATCH of clinical codes (ICD-10 diagnosis, HCPCS / CPT procedure) and a TAXONOMY of category PREFIXES (a code-group value-set) and DETERMINISTICALLY inserts the prefixes into a trie, then walks each code character-by-character down the trie remembering the DEEPEST terminal node reached — the longest taxonomy prefix that is a prefix of the code (the most specific category) — classifying each code to its most-specific category or leaving it unclassified when no prefix matches, and deriving the disposition: all-classified or unclassified-present. A shallow substring match (E28 when E28.3 also applies) mis-buckets a code into a less specific group; the longest-prefix rule picks the most specific category the taxonomy defines. It COMPLEMENTS, not duplicates, the other terminology / coding agents: distinct from the Identifier Validation agent (which validates an NPI's Luhn check digit), the Medication Name Safety agent (which flags look-alike drug names by edit distance), and the HCC Risk Adjustment agent (which scores confirmed conditions up a hierarchy) — this maps codes to a value-set taxonomy by longest prefix. TIME IS DATA: the classification is a pure function of the taxonomy + codes (no real clock, no randomness), so the same request always yields the same determination. A batch — all-classified / unclassified-present — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresCoderReview:true, autoApplied:false), which is how a legitimate classification is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.code.classifications-sourced (signal codeClassificationsSourced, violating value false) blocks a batch that doesn't correspond exactly to the submitted codes — exactly one classification per submitted code, in the same order (no fabricated code, none dropped, none duplicated), every matched prefix a SUBMITTED taxonomy prefix (no invented category), each classification self-consistent (a category iff a matched prefix), the counts adding up (classified + unclassified = total = codes), and the disposition following — the sourced + completeness gate (mirroring the Identifier Validation Agent's identifiers-sourced and the Enrollment Reconciliation Agent's reconciliation-complete) — backed by the pure guard classificationsSourced; policy.code.classification-consistent (signal codeClassificationConsistent, violating value false) blocks a wrong bucket or a missed match — rebuilding the trie from the taxonomy and re-running the longest-prefix match over each submitted code must reproduce the reported category + matched prefix — this is the load-bearing correctness gate, and it recomputes the match from the taxonomy INDEPENDENT of the reported classifications (it filters them to the ones whose code is a real submitted code before checking their category + prefix, so a fabricated-code classification that still reports a correct match fails sourced only, and a real-code but wrong-bucket classification fails consistent only — the two gates are isolable) (mirroring the Identifier Validation Agent's checksum-consistent and the Source Consensus Agent's consensus-consistent) — backed by the guard classificationConsistent; and policy.code.no-autonomous-recode (signal codeNoAutonomousRecode, violating value false) blocks a determination that autonomously re-coded a claim, submitted the codes, or overwrote the coded record (autoApplied:true — each is a consequential coding action that must be authorized) or did not require coder review (requiresCoderReview:false) — the agent CLASSIFIES on paper, and every classification is a RECOMMENDATION requiring a coder to confirm — backed by the guard noAutonomousRecode (mirroring the Identifier Validation Agent's no-autonomous-reject and the Enrollment Reconciliation Agent's no-autonomous-change; the harmful action is enforced-off). It is DELIBERATELY NOT PHI-bearing — a code is a terminology token, classified against a value-set taxonomy, not patient health information — so, like the Identifier Validation agent, it is NOT on the HIPAA-audit policy (phiAccessed:false throughout) and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/code-taxonomy/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — taxonomy.receive-codes → taxonomy.match-prefixes → taxonomy.classify-disposition → taxonomy.log-audit — with phiAccessed:false, returning the CodeTaxonomyDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Code Taxonomy panel (a mixed menopause / endocrine ICD-10 preset → unclassified-present with E28.310 bucketed to E28.3 not the shallower E28; an all-classified preset; a longest-prefix specificity preset (E28.319 → E28.3, E28.1 → E28); plus fabricated-code / wrong-bucket / auto-applied governance-block presets), a seeded taxonomy.receive-codes→match-prefixes→classify-disposition→log-audit trace showing the mixed case (4 of 5 codes classified, requiresCoderReview:true, phiAccessed:false), the console subtitle, and the investor brief (now 'ninety-four agents', with the Code Taxonomy agent on the data-substrate tier alongside the Identifier Validation and Source Consensus agents) all reflect it. Menopause-relevant: a menopause visit's diagnosis codes (E28.3 primary ovarian failure, N95.x menopausal disorders) and the endocrine comorbidities that ride alongside are exactly the codes this trie buckets to their most-specific value-set category — feeding quality measures, risk models, and analytics — without ever re-coding the claim on its own. Frontend tests green (3,996 tests — + code-taxonomy trie longest-prefix / shallow-fallback / no-match, mixed / all-classified / specificity / determinism, and three-guards-on-produced with fabricated-code + invented-category + count-mismatch + self-inconsistent + classifications-sourced-vs-classification-consistent-isolation + wrong-bucket + missed-match + auto-applied + skipped-review guard cases, the route's envelope / three governance blocks / mixed + all-classified + specificity happy paths with a non-PHI trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to ninety-four agents); the taxonomy + codes are clearly-labeled illustrative synthetics — NOT a certified terminology / code-set engine (real terminology services resolve full code systems — ICD-10-CM, SNOMED CT, LOINC, RxNorm — with versioned value sets, inclusion/exclusion logic, and semantic relationships, not a bare longest-prefix match). Lint + build clean.
Agent Fabric: added the Source-of-Truth Consensus / Golden-Record Field Reconciliation agent — deterministic Boyer–Moore majority vote that reconciles a field's conflicting source-system values into a golden-record value (consensus / no-consensus), with the per-source attribution sourced, a recomputing consensus, and never an autonomous golden-record write (the 93rd agent)
ShippedDetails
Added the ninety-third agent on the fabric — source-consensus-agent, a DETERMINISTIC (no-Claude) data-substrate master-data / golden-record service on the platform & data-substrate plane, reusing the existing data-plane tier as a SIBLING to the Enrollment Reconciliation, Master-Patient-Index, Identifier Validation, and Timeline Merge agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: it is NOT the Care Routing agent's DIJKSTRA'S WEIGHTED SHORTEST PATH, the KPI Trend agent's LEAST-SQUARES LINEAR REGRESSION, the Outreach Prioritization agent's 0/1 KNAPSACK DYNAMIC PROGRAMMING, the Quality Shift agent's CUSUM CHANGE-POINT DETECTION, the Timeline Merge agent's K-WAY MERGE OF SORTED STREAMS, the Reportable Condition agent's RECURSIVE BOOLEAN EXPRESSION-TREE EVALUATION, the PCP Matching agent's TWO-SIDED STABLE MATCHING (Gale–Shapley), the Network Adequacy agent's GEOSPATIAL GREAT-CIRCLE DISTANCE, the Identifier Validation agent's MODULAR-ARITHMETIC CHECKSUM, the Household Composition agent's UNION-FIND CONNECTED COMPONENTS, the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS, the MLR Rebate agent's LARGEST-REMAINDER APPORTIONMENT, the Medication Name Safety agent's STRING EDIT DISTANCE, the Schedule Conflict agent's GREEDY INTERVAL SELECTION, the Audit Log Integrity agent's HASH CHAIN, or the Claim Lifecycle agent's BFS REACHABILITY, and — CRUCIALLY — it is NOT the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE (which diffs WHO is on two rosters — enroll / terminate / update) or the Master-Patient-Index agent's WEIGHTED identity MATCHING (which decides whether two RECORDS are the same person): the heart of the service is the BOYER–MOORE MAJORITY VOTE — the classic linear-time, constant-space strict-majority election. In a new pure lib/source-consensus.ts, evaluateConsensus(request) takes a single logical FIELD whose value is reported by several SOURCE SYSTEMS (an EHR feed, a claims feed, a credentialing feed, an HIE feed) and DETERMINISTICALLY runs one cancellation pass (hold a candidate + a counter; increment on a match, decrement on a mismatch, reset the candidate when the counter hits zero) plus one verification pass confirming the survivor occurs in more than half the votes, deriving the disposition: consensus (a value carries a strict majority — with the winner, its count, and per-source agreement) or no-consensus (no value does). When two feeds disagree, a naive 'last write wins' or 'first source wins' silently picks a wrong value; a majority vote picks the value the SOURCES themselves corroborate. It COMPLEMENTS, not duplicates, the other data-plane agents: distinct from the Enrollment Reconciliation agent (a keyed set-difference between two rosters), the Master-Patient-Index agent (weighted record identity matching), and the Timeline Merge agent (a k-way merge of event streams) — this reconciles ONE field's conflicting source values into a golden-record value. TIME IS DATA: the consensus is a pure function of the votes themselves (no real clock, no randomness), so the same request always yields the same determination. A reconciliation — consensus / no-consensus — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresStewardReview:true, autoWritten:false), which is how a legitimate reconciliation is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.consensus.votes-sourced (signal consensusVotesSourced, violating value false) blocks a per-source attribution that doesn't correspond exactly to the submitted votes — every agreement must trace to a SUBMITTED vote (same sourceId + value; no fabricated source), every submitted vote must be attributed exactly once (none dropped, none double-listed), and the total must equal the number of votes — the sourced + completeness gate (mirroring the Enrollment Reconciliation Agent's reconciliation-complete and the Timeline Merge Agent's events-sourced) — backed by the pure guard votesSourced; policy.consensus.consensus-consistent (signal consensusConsistent, violating value false) blocks a wrong winner or a false consensus — re-running the Boyer–Moore majority vote over the submitted votes must reproduce the reported candidate, its count, the has-consensus flag, the disposition, and every real source's agreement flag — this is the load-bearing correctness gate, and it recomputes the winner from the votes INDEPENDENT of the reported agreements (it filters them to the ones that correspond to a real submitted vote before checking their flags, so a fabricated-source agreement that still reports the true winner fails sourced only, and a real-source but mis-flagged or wrong-winner determination fails consistent only — the two gates are isolable) (mirroring the Timeline Merge Agent's merge-consistent and the Identifier Validation Agent's checksum-consistent) — backed by the guard consensusConsistent; and policy.consensus.no-autonomous-write (signal consensusNoAutonomousWrite, violating value false) blocks a reconciliation that autonomously wrote the consensus value to the golden record / master data, overwrote a source system, or promoted a value to system-of-record (autoWritten:true — each is a data-integrity action that must be authorized) or did not require steward review (requiresStewardReview:false) — the agent RECONCILES on paper, and every reconciliation is a RECOMMENDATION requiring a data steward to confirm — backed by the guard noAutonomousWrite (mirroring the Timeline Merge Agent's no-autonomous-merge and the Enrollment Reconciliation Agent's no-autonomous-change; the harmful action is enforced-off). It is DELIBERATELY NOT PHI-bearing — a golden-record reference attribute (a provider's specialty, an org's tax id), not patient health information — so, like the Identifier Validation agent, it is NOT on the HIPAA-audit policy (phiAccessed:false throughout) and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/source-consensus/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — consensus.receive-votes → consensus.run-majority-vote → consensus.classify-consensus → consensus.log-audit — with phiAccessed:false, returning the ConsensusDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Source Consensus panel (a 4-of-5 provider-specialty preset → consensus 'Endocrinology'; a 2-2-1 network-status preset → no-consensus; a unanimous tax-id preset → consensus; plus fabricated-source / wrong-winner / auto-written governance-block presets), a seeded consensus.receive-votes→run-majority-vote→classify-consensus→log-audit trace showing the consensus case (candidate 'Endocrinology', 4 of 5 sources, requiresStewardReview:true, phiAccessed:false), the console subtitle, and the investor brief (now 'ninety-three agents', with the Source Consensus agent on the data-substrate tier alongside the Identifier Validation and Timeline Merge agents) all reflect it. Menopause-relevant: the gynecologists, endocrinologists, and compounding pharmacies a menopause plan lists carry a specialty, a network status, and an identifier that four different feeds each report differently — a majority vote across the sources is exactly what turns those conflicting feeds into one trustworthy directory value, without ever overwriting a system of record on its own. Frontend tests green (3,957 tests — + source-consensus boyer-moore strict-majority / plurality / unanimity / ordering, consensus / no-consensus / unanimous / determinism, and three-guards-on-produced with fabricated-source + dropped-source + total-mismatch + votes-sourced-vs-consensus-consistent-isolation + wrong-winner + false-consensus + mis-flagged-source + auto-written + skipped-review guard cases, the route's envelope / three governance blocks / consensus + no-majority + unanimous happy paths with a non-PHI trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to ninety-three agents); the fields + sources + values are clearly-labeled illustrative synthetics — NOT a certified master-data-management / golden-record system (real MDM weights sources by trust and recency, resolves value semantics, and survives field-by-field with lineage — not a bare majority of raw string votes). Lint + build clean.
Agent Fabric: added the Care-Transition Routing / Least-Burden Path agent — deterministic Dijkstra's weighted shortest path that finds the minimum-total-burden route from a patient's current care setting to a goal setting through a weighted graph of permitted transitions (route-found / no-route), with the path sourced, a recomputing optimal route, and never an autonomous transition (the 92nd agent)
ShippedDetails
Added the ninety-second agent on the fabric — care-routing-agent, a DETERMINISTIC (no-Claude) care-coordination / transition-planning service on the patient / clinical plane, reusing the existing care-coordination tier as a SIBLING to the Care Pathway, Transitions of Care, Caseload Balancing, Outreach Prioritization, and Schedule Conflict agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: it is NOT the KPI Trend agent's LEAST-SQUARES LINEAR REGRESSION, the Outreach Prioritization agent's 0/1 KNAPSACK DYNAMIC PROGRAMMING, the Quality Shift agent's CUSUM CHANGE-POINT DETECTION, the Timeline Merge agent's K-WAY MERGE OF SORTED STREAMS, the Reportable Condition agent's RECURSIVE BOOLEAN EXPRESSION-TREE EVALUATION, the PCP Matching agent's TWO-SIDED STABLE MATCHING (Gale–Shapley), the Network Adequacy agent's GEOSPATIAL GREAT-CIRCLE DISTANCE, the Identifier Validation agent's MODULAR-ARITHMETIC CHECKSUM, the Household Composition agent's UNION-FIND CONNECTED COMPONENTS, the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS, the MLR Rebate agent's LARGEST-REMAINDER APPORTIONMENT, the Medication Name Safety agent's STRING EDIT DISTANCE, the Schedule Conflict agent's GREEDY INTERVAL SELECTION, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, or the Audit Log Integrity agent's HASH CHAIN, and — CRUCIALLY — it is NOT the Care Pathway agent's TOPOLOGICAL ORDERING (which sequences ALL the required steps of ONE protocol into a dependency order — no weights, no source/target, no choosing among alternative routes), the Claim Lifecycle agent's BFS REACHABILITY (which finds the fewest-HOPS path across an UNWEIGHTED status state machine — edge count, not edge weight), or the Transitions of Care agent's MEDICATION RECONCILIATION (which reconciles meds across ONE encounter — it routes nothing): the heart of the service is DIJKSTRA'S WEIGHTED SHORTEST PATH — the classic single-source shortest-path over a graph with non-negative edge weights. In a new pure lib/care-routing.ts, evaluateCareRoute(request) takes a patient's current care SETTING (a start node), a goal setting, and a directed graph of PERMITTED transitions between settings each carrying a non-negative BURDEN weight (wait days + travel + cost proxy + risk), and DETERMINISTICALLY settles the nearest unsettled node and relaxes its out-edges (dist[v] = min(dist[v], dist[u] + w(u,v)); tie-break by lowest node id), reconstructs the minimum-total-weight path by walking predecessors back, and derives the disposition: route-found (with the path + total burden + hop count) or no-route (the goal is unreachable). A greedy or hand-picked route sends a patient the long way round — more waiting, more travel, more cost. It COMPLEMENTS, not duplicates, the other care-coordination agents: distinct from the Care Pathway agent (which topologically orders one protocol's steps), the Transitions of Care agent (medication reconciliation), and the Schedule Conflict agent (double-booking guard) — this finds the least-burden PATH through a weighted graph of care settings. TIME IS DATA: the route is a pure function of the graph's own edges + weights (no real clock, no randomness), so the same graph always yields the same route. A route — route-found / no-route — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresCareLeadReview:true, autoRouted:false), which is how a legitimate route is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.route.path-sourced (signal routePathSourced, violating value false) blocks a path that isn't a real walk of the submitted graph — for a route-found determination it must start at the start, end at the goal, every consecutive pair must be a SUBMITTED edge (no fabricated transition), and the totalCost must equal the sum of those edges' weights; an honest no-route must carry an empty path, a null cost, and reachable:false — the sourced + well-formedness gate (mirroring the Claim Lifecycle Agent's states-sourced and the Care Pathway Agent's steps-sourced) — backed by the pure guard pathSourced; policy.route.route-optimal (signal routeOptimal, violating value false) blocks a sub-optimal route or a false 'unreachable' — recomputing Dijkstra over the submitted edges must reproduce the reported minimum total burden, the reachable flag, and the disposition — this is the load-bearing correctness gate, and it recomputes the optimum from the edges INDEPENDENT of the reported path (it compares only the reported totalCost + reachability, so a fabricated-edge path that still reports the true optimum fails sourced only, and a real-edge but sub-optimal path fails optimal only — the two gates are isolable) (mirroring the Claim Lifecycle Agent's transition-consistent and the Outreach Agent's allocation-optimal) — backed by the guard routeOptimal; and policy.route.no-autonomous-routing (signal routeNoAutonomousRouting, violating value false) blocks a route that autonomously initiated the transition, booked the setting, or moved the patient (autoRouted:true — each is a care-delivery action that must be authorized) or did not require care-lead review (requiresCareLeadReview:false) — the agent ROUTES on paper, and every route is a RECOMMENDATION requiring a care lead to confirm — backed by the guard noAutonomousRouting (mirroring the Care Gap Agent's human-review posture and the Outreach Agent's no-autonomous-schedule; the harmful action is enforced-off). It IS PHI-bearing — the route is a patient's care plan — so it reuses, by extending appliesTo, the HIPAA-audit policy (phiAccessed:true throughout), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/care-routing/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — route.receive-graph → route.compute-path → route.classify-disposition → route.log-audit — with phiAccessed:true, returning the CareRouteDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Care Routing panel (a hospital→home discharge preset → route-found via SNF + home-health at total burden 7; a clinic→specialist preset → route-found on the cheapest direct edge; a goal-unreachable preset → no-route with an empty path; plus fabricated-transition / sub-optimal-route / auto-routed governance-block presets), a seeded route.receive-graph→compute-path→classify-disposition→log-audit trace showing the route-found case (path hospital → snf → home-health → home, total burden 7, hops 3, requiresCareLeadReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'ninety-two agents', with the Care Routing agent on the care-coordination tier alongside the Care Pathway and Transitions of Care agents) all reflect it. Menopause-relevant: a midlife woman being discharged from a hospital stay who could go home directly, via a skilled-nursing stay, or through home-health — each transition carrying its own wait, travel, and cost burden — is exactly the least-total-burden routing this Dijkstra path produces for her care team, without ever booking a bed or moving her on its own. Frontend tests green (3,917 tests — + care-routing dijkstra multi-hop / cheapest-direct / unreachable, route-found / direct / no-route / determinism, and three-guards-on-produced with fabricated-edge + wrong-start + total-mismatch + no-route-with-path + path-sourced-vs-route-optimal-isolation + sub-optimal + false-unreachable + auto-routed + skipped-review guard cases, the route's envelope / three governance blocks / route-found + direct + no-route happy paths with a PHI-bearing trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to ninety-two agents); the settings + transitions are clearly-labeled illustrative synthetics — NOT a certified care-transition / discharge-planning system (real transition planning weighs clinical appropriateness, bed availability, payer authorization, patient preference, and caregiver capacity — not a single scalar burden per edge). Lint + build clean.
Agent Fabric: added the Commercial KPI Trend & Projection agent — deterministic ordinary least-squares linear regression that fits a best-fit line to a business-metric series (slope + intercept + R²), classifies the trend rising / flat / declining, and projects the metric to a future horizon, with every point sourced, a recomputing fit, and never an autonomous forecast commit (the 91st agent, on the commercial CRM plane — no patient PHI)
ShippedDetails
Added the ninety-first agent on the fabric — kpi-trend-agent, a DETERMINISTIC (no-Claude) commercial-operations / analytics service on the COMMERCIAL CRM plane (NO patient PHI, NOT on the HIPAA-audit policy), reusing the existing commercial-operations tier as a SIBLING to the Pipeline Management, Account Management, Provider Contracting, Provider Benchmarking, and Deal Desk agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: it is NOT the Outreach Prioritization agent's 0/1 KNAPSACK DYNAMIC PROGRAMMING, the Quality Shift agent's CUSUM CHANGE-POINT DETECTION, the Timeline Merge agent's K-WAY MERGE OF SORTED STREAMS, the Reportable Condition agent's RECURSIVE BOOLEAN EXPRESSION-TREE EVALUATION, the PCP Matching agent's TWO-SIDED STABLE MATCHING (Gale–Shapley), the Network Adequacy agent's GEOSPATIAL GREAT-CIRCLE DISTANCE, the Identifier Validation agent's MODULAR-ARITHMETIC CHECKSUM, the Household Composition agent's UNION-FIND CONNECTED COMPONENTS, the MLR Rebate agent's LARGEST-REMAINDER APPORTIONMENT, the Claim Lifecycle agent's FSM TRANSITION VALIDATION, the Medication Name Safety agent's STRING EDIT DISTANCE, the Schedule Conflict agent's GREEDY INTERVAL SELECTION, the Caseload Balancing agent's GREEDY BIN-PACKING, the Care Pathway agent's TOPOLOGICAL ORDERING, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, or the Audit Log Integrity agent's HASH CHAIN, and — CRUCIALLY — it is NOT the Pipeline Management agent's FORECAST ROLLUP (which SUMS CRM opportunity records into committed / best-case figures — an aggregation of records, no fitted model), the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS (which ranks ONE value against a static distribution; it fits no line and projects nothing), the Quality Shift agent's CUSUM (which accumulates a running deviation to catch a SUSTAINED shift; it fits no model and extrapolates nothing), or the Remote Patient Monitoring agent's WINDOW-VS-BASELINE trend classification (which compares a recent window to a baseline window; it fits no line): the heart of the service is ORDINARY LEAST-SQUARES LINEAR REGRESSION — the closed-form best-fit line minimizing the sum of squared residuals. In a new pure lib/kpi-trend.ts, evaluateKpiTrend(request) takes a time-ordered series of a business METRIC (monthly provider-org adoption, active enrolled patients, ARR, bookings) plus a projection horizon and a flat tolerance, and DETERMINISTICALLY computes slope = (n·Σxy − Σx·Σy) / (n·Σx² − (Σx)²), intercept = (Σy − slope·Σx) / n, and R² = 1 − SSres/SStot, emits one fitted point per observation (with its fitted value + residual), classifies the trend rising / flat / declining against the flat tolerance, and projects ŷ = slope·horizon + intercept. A mis-fit line reports a trend the data doesn't support and a projection nobody should plan against. It COMPLEMENTS, not duplicates, the other commercial agents: distinct from the Pipeline Management agent (which rolls up opportunity records into a forecast) and the Account Management agent (which health-scores signed accounts) — this fits a least-squares trend line to a KPI series and projects it. TIME IS DATA: the fit is a pure function of the observations' own indices + values + the parameters (no real clock, no randomness), so the same series always yields the same line. A trend — rising / flat / declining — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresAnalystReview:true, autoCommitted:false), which is how a legitimate fit is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.kpi.series-sourced (signal kpiSeriesSourced, violating value false) blocks a fit not drawn from the submitted observations — every fitted point must trace to a SUBMITTED observation (same index + value; no fabricated point), every submitted observation must appear exactly once (none dropped, none double-plotted), and the fit parameters (horizon, flatTolerance) must be present numbers — the sourced + completeness gate (mirroring the Quality Shift Agent's observations-sourced and the Timeline Merge Agent's events-sourced) — backed by the pure guard seriesSourced; policy.kpi.fit-consistent (signal kpiFitConsistent, violating value false) blocks a mis-fit line — recomputing the ordinary least-squares regression over the submitted observations must reproduce the reported slope, intercept, R², trend classification, projection, and every point's fitted value + residual — this is the load-bearing correctness gate, and it recomputes the fit from the observations INDEPENDENT of the point-correspondence (a fabricated point is filtered out by the recompute, so it fails sourced while the real observations still recompute — the two gates are isolable) (mirroring the Quality Shift Agent's cusum-consistent and the Provider Benchmarking Agent's stats-consistent) — backed by the guard fitConsistent; and policy.kpi.no-autonomous-commit (signal kpiNoAutonomousCommit, violating value false) blocks a projection that autonomously committed itself as an official forecast, adjusted a quota / target, or notified finance (autoCommitted:true — each is a consequential commercial action that must be authorized) or did not require analyst review (requiresAnalystReview:false) — the agent PROJECTS, and every projection is a RECOMMENDATION requiring a revenue analyst to confirm — backed by the guard noAutonomousCommit (mirroring the Pipeline Management Agent's human-owner posture and the Account Management Agent's never-commit-a-contract posture; the harmful action is enforced-off). It operates ONLY on the commercial CRM plane — it carries NO patient PHI (phiAccessed:false throughout), is NOT on the HIPAA-audit policy, and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/kpi-trend/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — kpi.receive-series → kpi.fit-regression → kpi.classify-trend → kpi.log-audit — with phiAccessed:false, returning the KpiTrendDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new KPI Trend panel (a climbing-adoption preset → rising with a positive slope + high R² projected forward; a constant-metric preset → flat inside the tolerance band; a shrinking-cohort preset → declining projected lower; plus phantom-point / mis-fit-line / auto-committed governance-block presets), a seeded kpi.receive-series→fit-regression→classify-trend→log-audit trace showing the rising case (slope 11, R² 1, trend rising, projection 86, requiresAnalystReview:true, phiAccessed:false), the console subtitle, and the investor brief (now 'ninety-one agents', with the KPI Trend agent on the commercial-operations tier alongside the Pipeline Management and Account Management agents) all reflect it. Menopause-relevant only at the business layer: Pause's own go-to-market tracking provider-org adoption or enrolled-member growth month over month, whose slope + projection this least-squares fit reports for a revenue analyst — with no patient PHI ever touched and no forecast committed on its own. Frontend tests green (3,878 tests — + kpi-trend computeRegression rising / constant-R²-1 / single-point, classifyTrend, rising / flat / declining / determinism, and three-guards-on-produced with phantom-point + dropped-observation + value-mismatch + missing-parameter + sourced-vs-consistent-isolation + mis-fit-slope + fabricated-projection + wrong-trend + mis-computed-residual + auto-committed + skipped-review guard cases, the route's envelope / three governance blocks / rising + flat + declining happy paths with a non-PHI trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to ninety-one agents); the metrics are clearly-labeled illustrative synthetics carrying NO patient PHI — NOT a certified forecasting / FP&A system (real commercial forecasting weighs seasonality, pipeline mix, cohort dynamics, macro conditions, and human judgment — not a single straight line through past points). Lint + build clean.
Agent Fabric: added the Care-Management Capacity Allocation / Outreach Prioritization agent — deterministic 0/1 knapsack dynamic programming that, given a care team's fixed capacity (its outreach hours this cycle) and a set of candidate proactive interventions (each with an hours cost and a projected benefit), selects the max-benefit subset that fits the budget and defers (never denies) the rest, with every selection sourced, a recomputing optimal + feasible allocation, and never an autonomous schedule (the 90th agent)
ShippedDetails
Added the ninetieth agent on the fabric — outreach-prioritization-agent, a DETERMINISTIC (no-Claude) care-coordination / capacity-planning service on the patient / clinical plane, reusing the existing care-coordination tier as a SIBLING to the Caseload Balancing, Population Health, HEDIS Quality, Care Gap, PCP Matching, Reportable Condition, Quality Shift, and Schedule Conflict agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: it is NOT the Quality Shift agent's CUSUM CHANGE-POINT DETECTION, the Timeline Merge agent's K-WAY MERGE OF SORTED STREAMS, the Reportable Condition agent's RECURSIVE BOOLEAN EXPRESSION-TREE EVALUATION, the PCP Matching agent's TWO-SIDED STABLE MATCHING (Gale–Shapley), the Network Adequacy agent's GEOSPATIAL GREAT-CIRCLE DISTANCE, the Identifier Validation agent's MODULAR-ARITHMETIC CHECKSUM, the Household Composition agent's UNION-FIND CONNECTED COMPONENTS, the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS, the MLR Rebate agent's LARGEST-REMAINDER APPORTIONMENT, the Claim Lifecycle agent's FSM TRANSITION VALIDATION, the Medication Name Safety agent's STRING EDIT DISTANCE, the Schedule Conflict agent's GREEDY INTERVAL SELECTION, the Care Pathway agent's TOPOLOGICAL ORDERING, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, or the Audit Log Integrity agent's HASH CHAIN, and — CRUCIALLY — it is NOT the Caseload Balancing agent's GREEDY BIN-PACKING (which distributes EVERY member across managers' capacities by acuity — a partition where everyone is placed) or the Population Health agent's RISK RANKING (which orders a whole panel; it selects no subset under a budget): the heart of the service is the 0/1 KNAPSACK via DYNAMIC PROGRAMMING — the classic capacity-constrained maximum-value-subset optimization, filling a DP table dp[i][c] = max(dp[i-1][c], dp[i-1][c-cost_i] + benefit_i) and reconstructing the optimal set by walking the table back. In a new pure lib/outreach-prioritization.ts, evaluateOutreachPrioritization(request) takes a care team's fixed CAPACITY for the cycle (its available outreach HOURS this week) and a set of candidate proactive INTERVENTIONS (an HRT-titration call, a DEXA-screening reminder, an SDOH check-in, an education packet — each with an hours COST and a projected clinical BENEFIT) and DETERMINISTICALLY runs the 0/1 knapsack DP to select the subset that MAXIMIZES total projected benefit while fitting the capacity, defers (never denies) the rest, tallies the total cost / benefit + remaining capacity, and derives the disposition: all-scheduled (every candidate fits) or some-deferred. A greedy or hand-picked allocation leaves benefit on the table — patients who could have been reached this cycle are not. It COMPLEMENTS, not duplicates, the other care-coordination agents: distinct from the Caseload Balancing agent (which bin-packs a WHOLE panel across managers), the Population Health agent (which RANKS a panel by risk), and the Care Gap agent (which ACTS on a measure gap) — this selects a max-benefit SUBSET of interventions under a single capacity budget. TIME IS DATA: the allocation is a pure function of the candidates' own costs + benefits + the capacity (no real clock, no randomness), so the same request always yields the same plan. An allocation — all-scheduled or some-deferred — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresCareLeadReview:true, autoScheduled:false), which is how a legitimate allocation is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.outreach.selections-sourced (signal outreachSelectionsSourced, violating value false) blocks an allocation not built from the submitted candidates — every selected AND deferred intervention must trace to a SUBMITTED candidate (same id + cost + benefit; no fabricated intervention), every submitted candidate must appear exactly once across selected ∪ deferred (none dropped, none double-counted, none in both), and the tallies (total cost, total benefit, remaining capacity) must add up — the sourced + completeness gate (mirroring the Caseload Balancing Agent's assignment-complete and the Timeline Merge Agent's events-sourced) — backed by the pure guard selectionsSourced; policy.outreach.allocation-optimal (signal outreachAllocationOptimal, violating value false) blocks a sub-optimal / over-capacity allocation — recomputing the 0/1 knapsack DP over the submitted candidates + capacity must reproduce the reported maximum total benefit, and the reported selection must be FEASIBLE (its cost within capacity) and OPTIMAL (its benefit equals the DP optimum) — this is the load-bearing correctness gate, and it recomputes the optimum from the candidates INDEPENDENT of the selection-correspondence (a fabricated intervention is filtered out by the recompute, so it fails sourced while the real selection still recomputes — the two gates are isolable) (mirroring the Caseload Balancing Agent's capacity-respected and the Quality Shift Agent's cusum-consistent) — backed by the guard allocationOptimal; and policy.outreach.no-autonomous-schedule (signal outreachNoAutonomousSchedule, violating value false) blocks an allocation that autonomously launched the outreach, committed the plan, or booked the interventions (autoScheduled:true — each is a care-delivery action that must be authorized) or did not require care-lead review (requiresCareLeadReview:false) — the agent PRIORITIZES, and every allocation is a RECOMMENDATION requiring a care lead to confirm, with deferred interventions deferred to a later cycle, never denied — backed by the guard noAutonomousSchedule (mirroring the Caseload Balancing Agent's no-autonomous-assignment and the Care Gap Agent's human-review posture; the harmful action is enforced-off). It IS PHI-bearing — the interventions reference patients — so it reuses, by extending appliesTo, the HIPAA-audit policy (phiAccessed:true throughout), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/outreach-prioritization/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — outreach.receive-candidates → outreach.optimize-allocation → outreach.classify-disposition → outreach.log-audit — with phiAccessed:true, returning the OutreachDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Outreach Prioritization panel (a 10-hour-capacity preset → some-deferred with the max-benefit trio scheduled and the SDOH check-in deferred; an ample-capacity preset → all-scheduled; a 5-hour-capacity preset → two deferred; plus phantom-intervention / sub-optimal / auto-scheduled governance-block presets), a seeded outreach.receive-candidates→optimize-allocation→classify-disposition→log-audit trace showing the some-deferred case (selectedCount 3, totalBenefit 140, requiresCareLeadReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'ninety agents', with the Outreach Prioritization agent on the care-coordination tier alongside the Caseload Balancing and Population Health agents) all reflect it. Menopause-relevant: a menopause-care team with a fixed number of outreach hours this week and more high-value proactive touches (HRT-titration calls, DEXA reminders, SDOH check-ins, education) than it can complete is exactly the max-benefit-within-capacity selection this knapsack produces — deferring, never denying, the rest to next cycle, and never dialing a patient on its own. Frontend tests green (3,836 tests — + outreach-prioritization knapsack optimum / all-fit, some-deferred / all-scheduled / two-deferred / determinism, and three-guards-on-produced with phantom-intervention + dropped-candidate + cost-mismatch + miscounted-tally + sourced-vs-optimal-isolation + sub-optimal + over-capacity + auto-scheduled + skipped-review guard cases, the route's envelope / three governance blocks / some-deferred + all-scheduled + tight happy paths with a PHI-bearing trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to ninety agents); the interventions are clearly-labeled illustrative synthetics — NOT a certified care-management / capacity-planning system (real capacity planning weighs clinical urgency, member consent, staffing mix, regulatory timeliness, and equity — not a single benefit score under one hours budget; a deferred intervention is deferred, never denied). Lint + build clean.
Agent Fabric: added the Clinical Quality-Measure Shift Detection (Statistical Process Control) agent — deterministic change-point detection via a two-sided tabular CUSUM control chart that watches a clinical quality-measure series for a sustained shift away from its target (in-control / shift-up-detected / shift-down-detected), with every point sourced, a recomputing CUSUM, and never an autonomous intervention (the 89th agent)
ShippedDetails
Added the eighty-ninth agent on the fabric — quality-shift-agent, a DETERMINISTIC (no-Claude) care-coordination / quality-analytics service on the patient / clinical plane, reusing the existing care-coordination tier as a SIBLING to the Population Health, HEDIS Quality, Reportable Condition, PCP Matching, and Schedule Conflict agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: it is NOT the Timeline Merge agent's K-WAY MERGE OF SORTED STREAMS, the Reportable Condition agent's RECURSIVE BOOLEAN EXPRESSION-TREE EVALUATION, the PCP Matching agent's TWO-SIDED STABLE MATCHING (Gale–Shapley), the Network Adequacy agent's GEOSPATIAL GREAT-CIRCLE DISTANCE, the Identifier Validation agent's MODULAR-ARITHMETIC CHECKSUM, the Household Composition agent's UNION-FIND CONNECTED COMPONENTS, the MLR Rebate agent's LARGEST-REMAINDER APPORTIONMENT, the Claim Lifecycle agent's FSM TRANSITION VALIDATION, the Medication Name Safety agent's STRING EDIT DISTANCE, the Schedule Conflict agent's GREEDY INTERVAL SELECTION, the Caseload Balancing agent's GREEDY BIN-PACKING, the Care Pathway agent's TOPOLOGICAL ORDERING, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, or the Audit Log Integrity agent's HASH CHAIN, and — CRUCIALLY — it is NOT the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS (which ranks one value against a static peer distribution; this watches ONE series evolve over time) or the Access Anomaly agent's SLIDING-WINDOW COUNTING (which counts events in a fixed recent window to catch a spike; this accumulates a running deviation to catch a SUSTAINED small shift a window would miss): the heart of the service is CHANGE-POINT DETECTION via a two-sided TABULAR CUSUM (cumulative-sum) control chart. In a new pure lib/quality-shift.ts, evaluateQualityShift(request) takes a time-ordered series of a clinical QUALITY MEASURE (a weekly mammography-screening rate, a monthly HbA1c-control rate, a daily lab-QC value) plus a target, a slack k, and a decision threshold h, and DETERMINISTICALLY accumulates a one-sided upper sum SH_i = max(0, SH_{i-1} + (x_i − target) − k) and a one-sided lower sum SL_i = max(0, SL_{i-1} + (target − x_i) − k), signals the first observation whose SH or SL exceeds h (up wins a tie by documented precedence), and classifies the series as in-control / shift-up-detected / shift-down-detected. A missed shift lets a quality measure decay unnoticed; a false alarm sends a team chasing noise. It COMPLEMENTS, not duplicates, the other quality / clinical agents: distinct from the HEDIS agent (which COMPUTES a measure rate), the Population Health agent (which PRIORITIZES a panel by risk), the Provider Benchmarking agent (which RANKS a value against peers), and the Remote Monitoring agent (which checks ONE patient's vitals against a threshold) — this watches a quality-measure series for a SUSTAINED shift over time. TIME IS DATA: the chart is a pure function of the observations' own values + the parameters (no real clock, no randomness), so the same series always yields the same signal. A signal — in-control / shift-up-detected / shift-down-detected — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresQualityReview:true, autoActioned:false), which is how a legitimate signal is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.quality.observations-sourced (signal qualityObservationsSourced, violating value false) blocks a chart not drawn from the submitted observations — every charted point must trace to a SUBMITTED observation (same index + value; no fabricated point), every submitted observation must appear exactly once (none dropped, none double-charted), and the chart parameters (target, slack, threshold) must be present numbers — the sourced + completeness gate (mirroring the Timeline Merge Agent's events-sourced and the Enrollment Reconciliation Agent's reconciliation-complete) — backed by the pure guard observationsSourced; policy.quality.cusum-consistent (signal qualityCusumConsistent, violating value false) blocks a mis-charted CUSUM — recomputing the two-sided tabular CUSUM from the submitted observations + parameters must reproduce every charted SH_i / SL_i, the first-alarm index, the alarm direction, the signal, and the peak sums — this is the load-bearing correctness gate, and it recomputes the chart from the observations INDEPENDENT of the point-correspondence (a fabricated point is filtered out by the recompute, so it fails sourced while the real points still recompute — the two gates are isolable) (mirroring the Timeline Merge Agent's merge-consistent and the Provider Benchmarking Agent's stats-consistent) — backed by the guard cusumConsistent; and policy.quality.no-autonomous-intervention (signal qualityNoAutonomousIntervention, violating value false) blocks a detection that autonomously launched a corrective action, a recall / outreach campaign, or a process change (autoActioned:true — each is a consequential action that must be authorized) or did not require quality review (requiresQualityReview:false) — the agent DETECTS, and every signal is a RECOMMENDATION requiring a quality reviewer to confirm — backed by the guard noAutonomousIntervention (mirroring the HEDIS Agent's no-autonomous-submission and the Care Gap Agent's human-review posture; the harmful action is enforced-off). It charts DE-IDENTIFIED aggregate rate series, but because the measures are derived from patient clinical data it reuses, by extending appliesTo, the HIPAA-audit policy (phiAccessed:true throughout), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/quality-shift/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — quality.receive-series → quality.run-cusum → quality.classify-signal → quality.log-audit — with phiAccessed:true, returning the QualityShiftDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Quality Shift panel (a climbing-screening-rate preset → shift-up-detected when the upper CUSUM crosses h; a within-band preset → in-control; a falling-control-rate preset → shift-down-detected; plus phantom-point / mis-charted-CUSUM / auto-actioned governance-block presets), a seeded quality.receive-series→run-cusum→classify-signal→log-audit trace showing the shift-up case (signal shift-up-detected, alarmIndex 5, peakHigh 15, requiresQualityReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'eighty-nine agents', with the Quality Shift agent on the care-coordination tier alongside the Population Health and HEDIS agents) all reflect it. Menopause-relevant: a menopause-care program tracking its bone-density-screening or mammography-completion rate week over week, whose sustained downward drift is exactly the sustained shift this CUSUM chart catches before the care gap widens — without ever launching an outreach campaign on its own. Frontend tests green (3,798 tests — + quality-shift computeCusum / shift-up / in-control / shift-down / one-point-per-observation / determinism, and three-guards-on-produced with phantom-point + dropped-observation + value-mismatch + missing-parameter + sourced-vs-consistent-isolation + mis-charted-CUSUM + wrong-signal + wrong-alarm-index + auto-actioned + skipped-review guard cases, the route's envelope / three governance blocks / shift-up + in-control + shift-down happy paths with a PHI-bearing trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to eighty-nine agents); the measures are clearly-labeled illustrative de-identified aggregate rate series — NOT a certified SPC / quality-surveillance platform (real statistical process control tunes k and h to a target ARL, combines CUSUM with Shewhart / EWMA charts, and accounts for autocorrelation and measure specifications). Lint + build clean.
Agent Fabric: added the Clinical Event Timeline Merge / Multi-Source Record Reconciliation agent — deterministic k-way merge of sorted streams (the merge-k-sorted-lists / external-sort merge phase) that merges a patient's clinical events from several source streams into one chronological deduplicated timeline (clean-merge / duplicates-found), with every event sourced, a recomputing merge order + dedup, and never an autonomous write-back (the 88th agent)
ShippedDetails
Added the eighty-eighth agent on the fabric — timeline-merge-agent, a DETERMINISTIC (no-Claude) data-substrate / record-reconciliation service on the platform & data-substrate plane, reusing the existing data-plane tier as a SIBLING to the Master Patient Index, Provider-Identifier (NPI) Validation, Consent & Preferences, Break-the-Glass, and Audit-Log-Integrity agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: it is NOT the Reportable Condition agent's RECURSIVE BOOLEAN EXPRESSION-TREE EVALUATION, the PCP Matching agent's TWO-SIDED STABLE MATCHING (Gale–Shapley), the Network Adequacy agent's GEOSPATIAL GREAT-CIRCLE DISTANCE, the Identifier Validation agent's MODULAR-ARITHMETIC CHECKSUM, the Household Composition agent's UNION-FIND CONNECTED COMPONENTS, the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS, the MLR Rebate agent's LARGEST-REMAINDER APPORTIONMENT, the Claim Lifecycle agent's FSM TRANSITION VALIDATION, the Medication Name Safety agent's STRING EDIT DISTANCE, the Schedule Conflict agent's GREEDY INTERVAL SELECTION, the Caseload Balancing agent's GREEDY BIN-PACKING, the Access Anomaly agent's SLIDING-WINDOW COUNTING, the Care Pathway agent's TOPOLOGICAL ORDERING, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, or the Audit Log Integrity agent's HASH CHAIN, and — CRUCIALLY — it is NOT the Coverage Continuity agent's INTERVAL MERGING (which merges OVERLAPPING date SPANS into continuous coverage; this merges POINT events from many streams into one order) or the Master-Patient-Index agent's WEIGHTED identity MATCHING (which resolves WHO a record belongs to; this runs AFTER identity is known): the heart of the service is the K-WAY MERGE OF SORTED STREAMS — the classic 'merge k sorted lists' / external-sort merge phase that repeatedly takes the earliest head across the k stream cursors to produce one globally-ordered sequence in linear time, plus a content-key DEDUPLICATION pass. In a new pure lib/timeline-merge.ts, evaluateTimelineMerge(request) takes a patient's clinical EVENTS as they arrive in several already-sorted source STREAMS (an EHR, another EHR, a pharmacy, a claims feed — each stream in ascending time order) and DETERMINISTICALLY k-way merges them into one chronologically-ordered unified TIMELINE (ties broken by source then eventId), flags the DUPLICATES (the second-and-later report of the same clinical event, by content key), tallies the per-source contributions, and derives the disposition: clean-merge (no duplicates) or duplicates-found. A mis-ordered timeline hides a trend and a mis-flagged duplicate fakes a double dose. It COMPLEMENTS, not duplicates, the other data / provider agents: distinct from the Master Patient Index agent (which RESOLVES identity across systems), the Enrollment Reconciliation agent (a keyed set-difference between two rosters), and the Transitions of Care agent (medication reconciliation for ONE encounter) — this MERGES a patient's already-resolved event streams into one timeline. TIME IS DATA: the timeline is a pure function of the streams' own timestamps (no real clock, no randomness), so the same streams always yield the same timeline. A merge — clean-merge or duplicates-found — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresStewardReview:true, autoWritten:false), which is how a legitimate merge is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.timeline.events-sourced (signal timelineEventsSourced, violating value false) blocks a timeline not built from the submitted streams — every entry must trace to a SUBMITTED stream event (same source + eventId + timestamp + kind; no fabricated event), every submitted event must appear exactly once (none dropped, none double-listed), and the per-source contributions + tallies must add up — the sourced + completeness gate (mirroring the Enrollment Reconciliation Agent's reconciliation-complete and the Caseload Balancing Agent's assignment-complete) — backed by the pure guard eventsSourced; policy.timeline.merge-consistent (signal timelineMergeConsistent, violating value false) blocks a mis-ordered / mis-deduplicated timeline — recomputing the k-way merge from the submitted streams must reproduce the reported chronological order and duplicate flags (timestamps non-decreasing) — this is the load-bearing correctness gate, and it recomputes the merge from the streams INDEPENDENT of the submitted-event correspondence (a phantom entry is filtered out by the recompute, so a fabricated event fails sourced while the real events still recompute — the two gates are isolable) (mirroring the Reportable Condition Agent's classification-consistent and the Care Pathway Agent's sequence-valid) — backed by the guard mergeConsistent; and policy.timeline.no-autonomous-merge (signal timelineNoAutonomousMerge, violating value false) blocks a merge that autonomously wrote the timeline back to a source of record, purged a duplicate, or overwrote a chart (autoWritten:true — each is a data-integrity action that must be authorized) or did not require steward review (requiresStewardReview:false) — the agent MERGES, and every merge is a RECOMMENDATION requiring a data steward to confirm — backed by the guard noAutonomousMerge (mirroring the Enrollment Reconciliation Agent's no-autonomous-change and the Audit Log Integrity Agent's read-only posture; the harmful action is enforced-off). It IS PHI-bearing — the events are a patient's clinical data — so it reuses, by extending appliesTo, the HIPAA-audit policy (phiAccessed:true throughout), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/timeline-merge/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — timeline.receive-streams → timeline.merge-streams → timeline.classify-disposition → timeline.log-audit — with phiAccessed:true, returning the TimelineMergeDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Timeline Merge panel (a three-stream two-duplicate preset → duplicates-found with the duplicate visit + lab flagged; a distinct-events preset → clean-merge across two sources; a single-ordered-stream preset → clean-merge; plus phantom-event / out-of-order / auto-written governance-block presets), a seeded timeline.receive-streams→merge-streams→classify-disposition→log-audit trace showing the duplicates-found case (keptCount 4, duplicateCount 2, requiresStewardReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'eighty-eight agents', with the Timeline Merge agent on the data-plane tier alongside the Master Patient Index and the other data-substrate agents) all reflect it. Menopause-relevant: a 45-64 woman whose records are scattered across her gynecologist's EHR, a hospital, a pharmacy, and a claims feed — the same HRT start reported by two of them — is exactly the multi-source timeline this k-way merge unifies and de-duplicates for her care team, without ever overwriting a source chart on its own. Frontend tests green (3,759 tests — + timeline-merge kWayMerge / dedupKeyOf / duplicates-found / clean-merge / single-stream / determinism / per-source-tallies, and three-guards-on-produced with phantom-event + dropped-event + timestamp-mismatch + source-miscount + sourced-vs-consistent-isolation + out-of-order + wrong-dedup-flag + auto-written + skipped-review guard cases, the route's envelope / three governance blocks / duplicates-found + clean-merge + single-stream happy paths with a PHI-bearing trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to eighty-eight agents); the event streams are clearly-labeled illustrative synthetics — NOT a certified record-reconciliation / EMPI system (real reconciliation resolves identity first via an EMPI, reconciles with FHIR resource provenance, and applies source-of-truth precedence rules). Lint + build clean.
Agent Fabric: added the Reportable / Notifiable Condition Case Classification agent — deterministic recursive boolean expression-tree evaluation (a nested all-of / any-of / not case-definition tree over the case's facts) that classifies a patient case as confirmed / probable / suspect / not-a-case, with every criterion sourced, a recomputing classification, and never an autonomous public-health report (the 87th agent)
ShippedDetails
Added the eighty-seventh agent on the fabric — reportable-condition-agent, a DETERMINISTIC (no-Claude) care-coordination / public-health-compliance service on the patient / clinical plane, reusing the existing care-coordination tier as a SIBLING to the PCP Matching, Caseload Balancing, Care Team & Case Management, Schedule Conflict, and Population Health agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: it is NOT the PCP Matching agent's TWO-SIDED STABLE MATCHING (Gale–Shapley), the Network Adequacy agent's GEOSPATIAL GREAT-CIRCLE DISTANCE, the Identifier Validation agent's MODULAR-ARITHMETIC CHECKSUM, the Household Composition agent's UNION-FIND CONNECTED COMPONENTS, the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS, the MLR Rebate agent's LARGEST-REMAINDER APPORTIONMENT, the Claim Lifecycle agent's FSM TRANSITION VALIDATION, the Medication Name Safety agent's STRING EDIT DISTANCE, the Schedule Conflict agent's GREEDY INTERVAL SELECTION, the Caseload Balancing agent's GREEDY BIN-PACKING, the Access Anomaly agent's SLIDING-WINDOW COUNTING, the Coverage Continuity agent's INTERVAL MERGING, the Care Pathway agent's TOPOLOGICAL ORDERING, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, or the Audit Log Integrity agent's HASH CHAIN: the heart of the service is RECURSIVE BOOLEAN EXPRESSION-TREE EVALUATION — the recursive walk of a nested all-of (AND) / any-of (OR) / not (NOT) tree whose leaves are predicates over the case's facts, the exact shape a public-health case definition takes ('confirmed = lab-positive OR (clinically-compatible AND epi-linked)'). In a new pure lib/reportable-condition.ts, evaluateReportableCase(request) takes a patient CASE's structured facts plus a CASE DEFINITION (an ordered, highest-precedence-first list of classifications — confirmed / probable / suspect — each a nested criteria tree) and DETERMINISTICALLY evaluates each classification's tree recursively (a leaf is its fact's value, not negates, all-of is AND, any-of is OR), selects the highest-precedence classification whose tree holds (else not-a-case), and derives the reportable flag. A mis-evaluated tree over-reports a notifiable condition (a false alarm to public health) or under-reports it (a missed case). It COMPLEMENTS, not duplicates, the other compliance / clinical agents: distinct from the Adverse-Event Reporting agent (which DRAFTS a MedWatch / VAERS report for a drug / vaccine event), the Utilization Review agent (medical-necessity criteria for a service), and the Lab Result agent (a single analyte vs a reference range) — this classifies a case against a nested public-health CASE DEFINITION. TIME IS DATA: the classification is a pure function of the request's own facts + definition (no real clock, no randomness), so the same case always yields the same classification. A classification — confirmed / probable / suspect / not-a-case — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresEpiReview:true, autoReported:false), which is how a legitimate classification is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + boolean signal wired into the shared governance-signals metadata: policy.reportable.facts-sourced (signal caseFactsSourced, violating value false) blocks a classification not built from the submitted definition + facts — every leaf predicate must reference a SUBMITTED fact (no fabricated criterion inventing a requirement the definition never stated), the reported classification results must be exactly the definition's classifications in order, the referenced-fact set must match the definition's actual leaves, and the reported classification must be a defined one (or not-a-case) — the sourced + completeness gate (mirroring the PCP Matching Agent's matching-sourced and the Network Adequacy Agent's providers-sourced) — backed by the pure guard factsSourced; policy.reportable.classification-consistent (signal classificationConsistent, violating value false) blocks a mis-evaluated tree — recomputing the recursive boolean evaluation of each classification's criteria tree from the facts must reproduce each reported met flag, the selected classification (highest-precedence met tree, else not-a-case), and the reportable flag — this is the load-bearing correctness gate, and it recomputes the boolean recursion from the definition + facts INDEPENDENT of the submitted-fact correspondence (a phantom classification result is ignored by the recompute — scoped to the definition's classifications by name — so a fabricated result fails sourced while the real classifications still recompute, the two gates are isolable) (mirroring the PCP Matching Agent's matching-stable and the Care Pathway Agent's sequence-valid) — backed by the guard classificationConsistent; and policy.reportable.no-autonomous-report (signal noAutonomousReport, violating value false) blocks a classification that autonomously reported the case to a public-health authority (autoReported:true — a consequential legal action that must be authorized) or did not require epidemiologist review (requiresEpiReview:false) — the agent CLASSIFIES, and every classification is a RECOMMENDATION requiring an epidemiologist / infection-preventionist to confirm before any report is filed — backed by the guard noAutonomousReport (mirroring the Adverse-Event Reporting Agent's human-review posture and the HEDIS Agent's no-autonomous-submission; the harmful action is enforced-off). It IS PHI-bearing — the case is a patient's clinical data — so it reuses, by extending appliesTo, the HIPAA-audit policy (phiAccessed:true throughout), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/reportable-condition/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — rc.receive-case → rc.evaluate-criteria → rc.classify → rc.log-audit — with phiAccessed:true, returning the ReportableCaseDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Reportable Condition panel (a lab-positive-not-chronic preset → confirmed via (lab-positive OR antigen) AND NOT chronic; a clinical-plus-epi-linked preset → probable when no confirmed tree holds; a nothing-holds preset → not-a-case; plus phantom-classification / mis-evaluated-tree / auto-reported governance-block presets), a seeded rc.receive-case→evaluate-criteria→classify→log-audit trace showing the confirmed case (classification confirmed, reportable:true, requiresEpiReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'eighty-seven agents', with the Reportable Condition agent on the care-coordination tier alongside the PCP Matching and the other care-coordination agents) all reflect it. Menopause-relevant: a 45-64 woman presenting with an acute illness during a menopause-care encounter whose labs + clinical picture must be evaluated against a jurisdiction's notifiable-condition case definition is exactly the classification this recursive boolean tree produces — without ever filing a public-health report on its own. Frontend tests green (3,719 tests — + reportable-condition evaluateNode leaf / not / all-of / any-of / empty / nested recursion, referencedFactsOf, confirmed / probable / not-a-case / echo / determinism, and three-guards-on-produced with phantom-classification + fabricated-criterion + wrong-referenced-facts + sourced-vs-consistent-isolation + mis-evaluated-flag + wrong-precedence + wrong-reportable + auto-reported + skipped-review guard cases, the route's envelope / three governance blocks / confirmed + probable + not-a-case happy paths with a PHI-bearing trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to eighty-seven agents); the condition + definition + facts are clearly-labeled illustrative synthetics — NOT a certified surveillance / case-reporting system (real notifiable-condition reporting uses the jurisdiction's official CSTE / CDC case definitions, eCR / eICR electronic case reporting, and an epidemiologist's judgment). Lint + build clean.
Agent Fabric: added the Primary Care Provider (PCP) Assignment / Member–Provider Matching agent — deterministic two-sided stable matching (the member-proposing Gale–Shapley deferred-acceptance algorithm) that assigns a panel of members to primary care providers with no blocking pair (all-matched / partial-match), with every assignment sourced, a stable recompute, and never an autonomous commit (the 86th agent)
ShippedDetails
Added the eighty-sixth agent on the fabric — pcp-matching-agent, a DETERMINISTIC (no-Claude) care-coordination service on the patient / clinical plane, reusing the existing care-coordination tier as a SIBLING to the Caseload Balancing, Care Team & Case Management, Schedule Conflict, and Population Health agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: it is NOT the Network Adequacy agent's GEOSPATIAL GREAT-CIRCLE DISTANCE, the Identifier Validation agent's MODULAR-ARITHMETIC CHECKSUM, the Household Composition agent's UNION-FIND CONNECTED COMPONENTS, the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS, the Master-Patient-Index agent's WEIGHTED identity MATCHING, the MLR Rebate agent's LARGEST-REMAINDER APPORTIONMENT, the Claim Lifecycle agent's FSM TRANSITION VALIDATION, the Medication Name Safety agent's STRING EDIT DISTANCE, the Schedule Conflict agent's GREEDY INTERVAL SELECTION, the Access Anomaly agent's SLIDING-WINDOW COUNTING, the Coverage Continuity agent's INTERVAL MERGING, the Care Pathway agent's TOPOLOGICAL ORDERING, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, or the Audit Log Integrity agent's HASH CHAIN, and — CRUCIALLY — it is NOT the Caseload Balancing agent's GREEDY BIN-PACKING (which allocates a panel across managers' capacity by acuity, with NO preferences and NO stability guarantee): the heart of the service is TWO-SIDED STABLE MATCHING — the member-proposing Gale–Shapley DEFERRED-ACCEPTANCE algorithm (the many-to-one 'hospitals/residents' variant). In a new pure lib/pcp-matching.ts, evaluatePcpMatching(request) takes a panel of unassigned MEMBERS (each with a ranked list of preferred primary care providers) plus a set of PROVIDERS (each with a panel CAPACITY and a ranked list of the members it would accept) and DETERMINISTICALLY runs the member-proposing deferred acceptance — free members propose down their lists in id order, each provider tentatively holds up to its capacity of its most-preferred acceptable proposers and rejects the rest, rejected members propose on — terminating at the member-optimal STABLE matching (the unique assignment with no blocking pair), recording one assignment per member (with the member's 1-based preference rank), the provider loads, and the disposition: all-matched (every member matched to a preferred provider) or partial-match (some members unmatched — capacity exhausted or short preference lists). A matching that leaves a member and a provider who each prefer the other over their current lot (a BLOCKING pair) is UNSTABLE — it unravels as the pair defects, leaving a patient without a real PCP. It COMPLEMENTS, not duplicates, the other care-coordination agents: distinct from the Caseload Balancing agent (which BIN-PACKS a panel across managers' capacity to balance load, no preferences), the Care Team & Case Management agent (the multi-disciplinary team around ONE patient), the Transitions of Care agent (moving ONE patient), and the Population Health agent (prioritizing a panel) — this produces a STABLE two-sided matching of members to primary care providers. TIME IS DATA: the matching is a pure function of the request's own preferences + capacities (no real clock, no randomness; the free members propose in a deterministic id order), so the same panel always yields the same matching. A matching — all-matched or partial-match — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresCoordinatorReview:true, autoAssigned:false), which is how a legitimate matching is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.pcp.matching-sourced (signal matchingSourced, violating value false) blocks a matching not built from the submitted panel — one assignment per SUBMITTED member (all present, none dropped or invented), every assigned provider a SUBMITTED provider, the provider loads echoing the submitted capacities + actual assignment counts, and the matched / unmatched / total tallies agreeing — the sourced + completeness gate (mirroring the Network Adequacy Agent's providers-sourced and the Caseload Balancing Agent's assignment-complete) — backed by the pure guard matchingSourced; policy.pcp.matching-stable (signal matchingStable, violating value false) blocks an unstable / mis-recomputed matching — recomputing the Gale–Shapley deferred acceptance from the echoed preferences + capacities must reproduce the reported assignment + each member's preference rank, no provider may be over capacity, and there must be NO blocking pair — this is the load-bearing correctness gate, and it recomputes the matching from the preferences INDEPENDENT of the submitted-list↔assignment correspondence (a phantom member is ignored by the recompute, so a fabricated assignment fails sourced while the real members still recompute stably — the two gates are isolable) (mirroring the Network Adequacy Agent's distances-consistent and the Household Composition Agent's partition-consistent) — backed by the guard matchingStable (with a hasBlockingPair helper that directly checks capacity + blocking pairs); and policy.pcp.no-autonomous-assignment (signal pcpNoAutonomousAssignment, violating value false) blocks a matching that autonomously committed an assignment, reassigned a patient, or overrode a provider's panel (autoAssigned:true — each is a care-ownership decision that must be authorized) or did not require coordinator review (requiresCoordinatorReview:false) — the agent PROPOSES a matching, and every matching is a RECOMMENDATION requiring a care-coordination lead to confirm — backed by the guard noAutonomousAssignment (mirroring the Caseload Balancing Agent's and the Care Team Agent's no-autonomous-assignment posture; the harmful action is enforced-off). It IS PHI-bearing — the members are patients — so it reuses, by extending appliesTo, the HIPAA-audit policy (phiAccessed:true throughout), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/pcp-matching/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — pcp.receive-panel → pcp.run-deferred-acceptance → pcp.classify-disposition → pcp.log-audit — with phiAccessed:true, returning the PcpMatchingDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new PCP Matching panel (an interlocking-preferences preset → a stable all-matched result m1→p2 / m2→p1 / m3→p3; a capacity-exhausted preset → a stable partial-match leaving one member unmatched; a capacity-2 preset → a provider whose panel of two absorbs two members; plus phantom-member / unstable-matching / auto-assigned governance-block presets), a seeded pcp.receive-panel→run-deferred-acceptance→classify-disposition→log-audit trace showing the all-matched case (matchedCount 3, unmatchedCount 0, requiresCoordinatorReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'eighty-six agents', with the PCP Matching agent on the care-coordination tier alongside the Caseload Balancing and the other care-coordination agents) all reflect it. Menopause-relevant: a 45-64 woman newly enrolling who ranks the in-network gynecologists and internists she'd accept as her PCP, matched against those providers' panel capacities, is exactly the stable assignment this Gale–Shapley matching produces — without ever committing her to a panel on its own. Frontend tests green (3,678 tests — + pcp-matching deferred-acceptance / capacity-exhausted / capacity-2 plus all-matched / partial-match / provider-loads / member+provider-echo / determinism, hasBlockingPair stable / blocking-pair / over-capacity, and three-guards-on-produced with phantom-member + provider-load-miscount + off-network-provider + sourced-vs-stable-isolation + unstable-blocking-pair + wrong-rank + wrong-disposition + auto-assigned + skipped-review guard cases, the route's envelope / three governance blocks / all-matched + partial-match + capacity-2 happy paths with a PHI-bearing trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to eighty-six agents); the members + providers + preferences + capacities are clearly-labeled illustrative synthetics, NOT a certified panel-management system — real PCP assignment also weighs geography, language, continuity of care, plan-network rules, and member choice, and runs against a live attribution system. Lint + build clean.
Agent Fabric: added the Network Adequacy / Time-and-Distance agent — deterministic geospatial great-circle (haversine) distance + nearest-neighbor scan + threshold that decides whether a plan's in-network providers meet a required specialty's time-and-distance adequacy standard (adequacy-met / adequacy-gap), with every provider sourced, exact recomputed distances, and never an autonomous certification (the 85th agent)
ShippedDetails
Added the eighty-fifth agent on the fabric — network-adequacy-agent, a DETERMINISTIC (no-Claude) claims / payer-operations service on the payer & plan operations plane, reusing the existing payer-operations tier as a SIBLING to the Enrollment Reconciliation, Coordination of Benefits, Member Cost-Share, Household Composition, and Claim Lifecycle agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: it is NOT the Identifier Validation agent's MODULAR-ARITHMETIC CHECKSUM (the NPI Luhn check digit), the Household Composition agent's UNION-FIND / DISJOINT-SET CONNECTED COMPONENTS, the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS, the Master-Patient-Index agent's WEIGHTED identity MATCHING, the Claim Lifecycle agent's FSM TRANSITION VALIDATION, the Medication Name Safety agent's STRING EDIT DISTANCE, the Schedule Conflict agent's GREEDY INTERVAL SELECTION, the Caseload Balancing agent's GREEDY BIN-PACKING, the Access Anomaly agent's SLIDING-WINDOW COUNTING, the Coverage Continuity agent's INTERVAL MERGING, the Care Pathway agent's TOPOLOGICAL ORDERING, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, or the Audit Log Integrity agent's HASH CHAIN: the heart of the service is GEOSPATIAL GREAT-CIRCLE DISTANCE — the haversine formula that converts two (latitude, longitude) pairs into a distance in miles, plus a NEAREST-NEIGHBOR scan and a THRESHOLD comparison against the regulatory standard. In a new pure lib/network-adequacy.ts, evaluateNetworkAdequacy(request) takes a MEMBER's location plus the plan's IN-NETWORK PROVIDERS (each with a specialty + coordinates) and a required specialty + a time-and-distance standard (miles), and DETERMINISTICALLY filters the providers to the required specialty, computes the haversine great-circle distance from the member to each, sorts ascending (with a stable providerId tie-break), takes the NEAREST, and derives the disposition: adequacy-met (a nearest in-network provider within the standard) or adequacy-gap (the nearest exceeds the standard, or there is NO in-network provider of that specialty at all — a null nearest). A member with no in-network specialist within the standard distance has a network-adequacy GAP — both a compliance failure (CMS 42 CFR 422.116 / state QHP time-and-distance standards) and an access-to-care failure. It COMPLEMENTS, not duplicates, the other provider / network agents: distinct from the Provider Credentialing agent (whether a provider is QUALIFIED and in the directory), the Referral Management agent (routing a specific referral), and the Provider Benchmarking agent (a provider's cost / quality percentile) — this measures whether the network is geographically ADEQUATE. TIME IS DATA: the finding is a pure function of the request's own coordinates + standard (no real clock, no randomness), so the same request always yields the same result. A finding — adequacy-met or adequacy-gap — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresNetworkReview:true, autoCertified:false), which is how a legitimate finding is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.adequacy.providers-sourced (signal providersSourced, violating value false) blocks a finding not built from the submitted in-network providers — every evaluated provider must be a SUBMITTED one (same id + coordinates + the required specialty; no PHANTOM provider fabricating coverage that isn't in the network), every submitted provider of that specialty must be evaluated (none dropped), the counts must agree, and the nearest must be one of the evaluated — the sourced + completeness gate (mirroring the Identifier Validation Agent's identifiers-sourced and the Household Composition Agent's links-sourced) — backed by the pure guard providersSourced; policy.adequacy.distances-consistent (signal distancesConsistent, violating value false) blocks a finding whose distances do not recompute — recomputing the haversine distance from the member to each evaluated provider's OWN coordinates must reproduce every reported distance, the ascending order, the nearest, the nearest distance, and the adequacy disposition against the standard; a mis-measured distance understates a gap (falsely certifying adequacy so a member can't reach care) or overstates one — this is the load-bearing correctness gate, and it recomputes the geometry from the evaluated rows' coordinates INDEPENDENT of the providers↔evaluated correspondence (a phantom provider's coordinates recompute self-consistently, so a fabricated provider fails sourced while the distances still recompute — the two gates are isolable) (mirroring the Medication Name Safety Agent's distances-consistent and the Provider Benchmarking Agent's stats-consistent) — backed by the guard distancesConsistent; and policy.adequacy.no-autonomous-network-change (signal noAutonomousNetworkChange, violating value false) blocks a finding that autonomously certified the network as adequate to a regulator, closed a gap, or added / removed a provider (autoCertified:true — each is a consequential action that must be authorized) or did not require network review (requiresNetworkReview:false) — the agent ASSESSES adequacy, and every finding is a RECOMMENDATION requiring a network manager to confirm — backed by the guard noAutonomousNetworkChange (mirroring the Provider Benchmarking Agent's no-autonomous-tiering and the Provider Credentialing Agent's no-referral-to-expired-or-sanctioned posture; the harmful action is enforced-off). It IS PHI-bearing — the member's location + the specialty they need is health information — so it reuses, by extending appliesTo, the HIPAA-audit policy (phiAccessed:true throughout), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/network-adequacy/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — adequacy.receive-request → adequacy.compute-distances → adequacy.classify-disposition → adequacy.log-audit — with phiAccessed:true, returning the NetworkAdequacyDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Network Adequacy panel (a cardiology-within-10-mi preset → adequacy-met with the nearest of two cardiologists 0.54 mi away; an endocrinology-too-far preset → adequacy-gap with both endocrinologists beyond the 10 mi standard; a no-in-network-specialist preset → adequacy-gap with a null nearest; plus phantom-provider / mis-measured-distance / auto-certified governance-block presets), a seeded adequacy.receive-request→compute-distances→classify-disposition→log-audit trace showing the endocrinology gap (matchingProviderCount 2, nearest 16.44 mi, adequacy-gap, requiresNetworkReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'eighty-five agents', with the Network Adequacy agent on the payer-operations tier alongside the Household Composition and the other member / enrollment agents) all reflect it. Menopause-relevant: a 45-64 woman who needs an in-network gynecologist or endocrinologist for menopause care but whose nearest one is 30 miles away has exactly the network-adequacy gap this haversine distance surfaces to a network manager — without ever certifying the network as adequate on its own. Frontend tests green (3,635 tests — + network-adequacy haversine zero / known-distance / symmetry plus adequacy-met / ascending-sort / adequacy-gap / no-provider-null-nearest / member+provider-echo / determinism and three-guards-on-produced with phantom-provider + dropped-provider + count-mismatch + sourced-vs-consistent-isolation + mis-measured-distance + wrong-disposition + wrong-nearest + phantom-geometry-isolation + auto-certified + skipped-review guard cases, the route's envelope / three governance blocks / adequacy-met + adequacy-gap + no-provider happy paths with a PHI-bearing trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to eighty-five agents); the member + providers + coordinates are clearly-labeled illustrative synthetics, computing STRAIGHT-LINE great-circle distance only — NOT drive time / road distance, and NOT the full CMS / state ratio, county-designation, provider-capacity, or telehealth rules — NOT a certified network-adequacy engine. Lint + build clean.
Agent Fabric: added the Provider Identifier (NPI) Validation & Integrity agent — deterministic modular-arithmetic checksum (the CMS/NPI Luhn mod-10 check digit over the 80840 prefix + the 9-digit base) that validates a batch of NPIs as valid / invalid-format / invalid-checksum, with every result sourced, an exact recomputed check digit, and never an autonomous reject (the 84th agent)
ShippedDetails
Added the eighty-fourth agent on the fabric — identifier-validation-agent, a DETERMINISTIC (no-Claude) platform / data-substrate integrity service on the platform & data substrate plane, reusing the existing data-plane tier as a SIBLING to the Master Patient Index, Break-the-Glass, De-Identification, Minimum-Necessary, and Audit Log Integrity agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: it is NOT the Household Composition agent's UNION-FIND / DISJOINT-SET CONNECTED COMPONENTS, the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS, the Master-Patient-Index agent's WEIGHTED identity MATCHING, the Claim Lifecycle agent's FSM TRANSITION VALIDATION, the Medication Name Safety agent's STRING EDIT DISTANCE, the Schedule Conflict agent's GREEDY INTERVAL SELECTION, the Caseload Balancing agent's GREEDY BIN-PACKING, the Access Anomaly agent's SLIDING-WINDOW COUNTING, the Coverage Continuity agent's INTERVAL MERGING, the Care Pathway agent's TOPOLOGICAL ORDERING, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, the Member Cost-Share agent's SEQUENTIAL dollar waterfall, the DDI agent's PAIRWISE KNOWLEDGE-BASE LOOKUP, or the Audit Log Integrity agent's HASH CHAIN: the heart of the service is a MODULAR-ARITHMETIC CHECKSUM — the Luhn (mod-10) check-digit computation the NPI standard uses. In a new pure lib/identifier-validation.ts, evaluateIdentifierValidation(request) takes a batch of National Provider Identifiers and DETERMINISTICALLY validates each one: the format (exactly 10 decimal digits beginning with 1 or 2) and the check digit — the 10th digit must equal the Luhn checksum recomputed over the '80840' ISO issuer prefix + the first 9 digits (doubling every second digit from the right, summing, and taking (10 − sum mod 10) mod 10) — classifying each as valid, invalid-format, or invalid-checksum (a well-formed NPI whose 10th digit does not match the recomputed check digit — a likely transposition / typo), tallying the per-kind counts, and deriving the batch disposition: all-valid or invalids-flagged. An NPI with a transposed or mistyped digit fails the checksum; catching it before it lands on a claim or in a provider directory prevents a claim rejection or a ghost-directory entry. It COMPLEMENTS, not duplicates, the other provider-data agents: distinct from the Provider Credentialing agent (which cites an npi-registry as a verification SOURCE but does not validate the check digit) and the OIG Exclusion agent (which MATCHES an NPI against the sanctions list) — this validates that the NPI itself is well-formed and its check digit is correct. TIME IS DATA: the finding is a pure function of the request's own identifiers (no real clock, no randomness), so the same batch always yields the same result. A finding — all-valid or invalids-flagged — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresStewardReview:true, autoRejected:false), which is how a legitimate finding is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.identifier.identifiers-sourced (signal identifiersSourced, violating value false) blocks a finding not built from the submitted batch — there must be one result per submitted identifier (same NPI, same order; no fabricated result, no dropped identifier), the reported total must equal the identifier count, the per-kind counts must sum to the total, and the batch disposition must follow — the sourced + completeness gate (mirroring the Household Composition Agent's links-sourced and the Enrollment Reconciliation Agent's reconciliation-complete) — backed by the pure guard identifiersSourced; policy.identifier.checksum-consistent (signal checksumConsistent, violating value false) blocks a finding whose checksums do not recompute — recomputing each identifier's format classification and Luhn check digit from the NPI itself must reproduce the reported disposition, expected check digit, and per-kind counts; a miscomputed checksum waves through a mistyped NPI or fails a correct one — this is the load-bearing correctness gate, and it recomputes each result from its own NPI INDEPENDENT of the identifiers↔results correspondence (a fabricated extra result recomputes self-consistently, so it fails sourced while the checksums still recompute — the two gates are isolable) (mirroring the Provider Benchmarking Agent's stats-consistent and the OIG Exclusion Agent's match-not-overstated) — backed by the guard checksumConsistent; and policy.identifier.no-autonomous-reject (signal identifierNoAutonomousReject, violating value false) blocks a finding that autonomously rejected a claim, removed a provider from the directory, or corrected a number (autoRejected:true — each is a consequential action that must be authorized) or did not require steward review (requiresStewardReview:false) — the agent VALIDATES and FLAGS, and every finding is a RECOMMENDATION requiring a data steward to confirm — backed by the guard identifierNoAutonomousReject (mirroring the Provider Credentialing Agent's no-referral-to-expired-or-sanctioned and the Enrollment Reconciliation Agent's no-autonomous-change posture; the harmful action is enforced-off). It is DELIBERATELY NOT PHI-bearing — an NPI is a PROVIDER identifier, not patient health information — so, like the OIG Exclusion agent, it is NOT on the HIPAA-audit policy (phiAccessed:false throughout); it is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/identifier-validation/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — identifier.receive-batch → identifier.validate-checksums → identifier.classify-disposition → identifier.log-audit — with NO phiAccessed marker, returning the IdentifierValidationDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Identifier Validation panel (a 3-NPI preset → 1 valid, 1 transposed (invalid-checksum), 1 malformed (invalid-format); an all-valid preset → 3 well-formed NPIs with correct check digits; a single-malformed preset → invalid-format on a leading-3 NPI; plus fabricated-identifier / miscomputed-checksum / auto-rejected governance-block presets), a seeded identifier.receive-batch→validate-checksums→classify-disposition→log-audit trace showing the mixed batch (validCount 1, invalidFormatCount 1, invalidChecksumCount 1, requiresStewardReview:true, NOT PHI), the console subtitle, and the investor brief (now 'eighty-four agents', with the Identifier Validation agent on the data-plane tier alongside the Master Patient Index and the other platform agents) all reflect it. Menopause-relevant: the gynecologists, endocrinologists, and compounding pharmacies a menopause plan pays each carry an NPI on every claim and directory entry — a single transposed digit is exactly what this checksum catches before it becomes a claim rejection or a ghost-directory listing that keeps a patient from finding a specialist. Frontend tests green (3,592 tests — + identifier-validation check-digit / mixed-batch / all-valid / single-malformed / non-digit / leading-digit-range / 2-prefix / empty-batch / identifier-echo / determinism plus three-guards-on-produced with fabricated-result + counts-don't-sum + disposition-mismatch + result-npi-mismatch + reported-as-valid + wrong-counts + sourced-vs-consistent-isolation + auto-rejected + skipped-review guard cases, the route's envelope / three governance blocks / invalids-flagged + all-valid + single-malformed happy paths with a NOT-PHI trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to eighty-four agents); the identifiers are clearly-labeled illustrative synthetics, and this validates STRUCTURE + check digit only — it does NOT confirm the NPI is assigned, active, or belongs to a particular provider (that requires an NPPES / registry lookup). Lint + build clean.
Agent Fabric: added the Household / Family-Unit Composition agent — deterministic union-find / disjoint-set connected components that groups plan members into households by the transitive closure of their relationship links, with every link + household sourced, an exact recomputed partition, and never an autonomous merge (the 83rd agent)
ShippedDetails
Added the eighty-third agent on the fabric — household-composition-agent, a DETERMINISTIC (no-Claude) claims / payer-operations service on the payer & plan operations plane, reusing the existing payer-operations tier as a SIBLING to the Enrollment Reconciliation, Coordination of Benefits, Member Cost-Share, and Claim Lifecycle agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: it is NOT the Provider Benchmarking agent's PERCENTILE / RANK STATISTICS, the Claim Lifecycle agent's FSM TRANSITION VALIDATION, the Medication Name Safety agent's STRING EDIT DISTANCE, the Schedule Conflict agent's GREEDY INTERVAL SELECTION, the Caseload Balancing agent's GREEDY BIN-PACKING, the Access Anomaly agent's SLIDING-WINDOW COUNTING, the Coverage Continuity agent's INTERVAL MERGING, the Care Pathway agent's TOPOLOGICAL ORDERING, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, the Member Cost-Share agent's SEQUENTIAL dollar waterfall, the DDI agent's PAIRWISE KNOWLEDGE-BASE LOOKUP, or the Audit Log Integrity agent's HASH CHAIN, and — CRUCIALLY — it is NOT the Master-Patient-Index agent's identity MATCHING (which links records of the SAME person across systems; THIS one instead groups DIFFERENT people who share a household): the heart of the service is UNION-FIND / DISJOINT-SET CONNECTED COMPONENTS — clustering members by the transitive closure of their relationship links. In a new pure lib/household-composition.ts, evaluateHouseholdComposition(request) takes a batch of plan MEMBERS plus a set of PAIRWISE relationship LINKS (shared subscriber, shared address, a tax-dependent tie) and DETERMINISTICALLY de-dupes the members, unions every link whose BOTH endpoints are submitted members (a link to a non-member is ignored — it can't join the graph), groups members by their set representative (with path compression; the lexicographically smaller id becomes the root), sorts each household's members, and assigns deterministic household ids (hh-1, hh-2, … by each component's minimum member) — so a member linked to a member linked to a third all land in ONE household even when the first and third are NOT directly linked (transitivity) — and derives the disposition: all-singletons (no household has more than one member — no links formed a group) or households-formed (at least one multi-member household). It COMPLEMENTS, not duplicates, the other member / enrollment agents: distinct from the Master-Patient-Index agent (same-person matching), the Enrollment Reconciliation agent (WHO is enrolled between employer and carrier via a keyed set-difference), and the Coordination of Benefits agent (the ORDER of a member's coverages) — this GROUPS distinct members into family units. A household drives a family deductible / out-of-pocket maximum, household-level outreach, and consent scoping; a wrong grouping mis-applies a family accumulator or LEAKS one member's data to another. TIME IS DATA: the finding is a pure function of the request's own members + links (no real clock, no randomness), so the same input always yields the same households. A finding — all-singletons or households-formed — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresStewardReview:true, autoMerged:false), which is how a legitimate finding is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.household.links-sourced (signal householdLinksSourced, violating value false) blocks a finding not built from the submitted batch — every link must connect two SUBMITTED members (no phantom relationship to a member not in the batch), and the households must PARTITION exactly the submitted members (each member in exactly one household, all covered, none invented) — the sourced + completeness gate (mirroring the Enrollment Reconciliation Agent's reconciliation-complete and the Caseload Balancing Agent's assignment-complete) — backed by the pure guard householdLinksSourced; policy.household.partition-consistent (signal householdPartitionConsistent, violating value false) blocks a finding whose grouping does not add up — recomputing the union-find from the echoed members + links must reproduce the reported households (same ids, members, sizes), household count, largest-household size, member count, and disposition; a wrong grouping (two unlinked members merged, or two linked members split apart) mis-applies a family accumulator or leaks data — this is the load-bearing correctness gate, and it recomputes the connected components from the links INDEPENDENT of the sourced check (a phantom link endpoint is ignored by the recompute, so a fabricated link fails sourced while the partition still recomputes — the two gates are isolable) (mirroring the Provider Benchmarking Agent's stats-consistent and the Claim Lifecycle Agent's transition-consistent) — backed by the guard householdPartitionConsistent; and policy.household.no-autonomous-merge (signal householdNoAutonomousMerge, violating value false) blocks a finding that autonomously merged member records, changed enrollment, or applied a family accumulator (autoMerged:true — each is a consequential action that must be authorized) or did not require steward review (requiresStewardReview:false) — the agent PROPOSES a grouping, and every finding is a RECOMMENDATION requiring a data steward to confirm — backed by the guard householdNoAutonomousMerge (mirroring the Enrollment Reconciliation Agent's no-autonomous-change and the Master-Patient-Index Agent's no-autonomous-merge posture; the harmful action is enforced-off). It IS PHI-bearing — the members are patients — so it reuses, by extending appliesTo, the HIPAA-audit policy (phiAccessed:true throughout), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/household-composition/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — household.receive-batch → household.compute-components → household.classify-disposition → household.log-audit — with phiAccessed:true, returning the HouseholdCompositionDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Household Composition panel (a 6-member preset → 3 households showing a transitive 3-member family, a pair, and a singleton; a 5-member-chain preset → one household of 5 proving transitivity when m1 and m5 are never directly linked; a no-links preset → all-singletons; plus phantom-link / mis-grouped-partition / auto-merged governance-block presets), a seeded household.receive-batch→compute-components→classify-disposition→log-audit trace showing the 6-member / 3-household case (householdCount 3, largest 3, requiresStewardReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'eighty-three agents', with the Household Composition agent on the payer-operations tier alongside the Enrollment Reconciliation and the other member / enrollment agents) all reflect it. Menopause-relevant: a 45-64 woman, her spouse, and a dependent on one plan — linked by a shared subscriber and address — are exactly the household this connected-components grouping assembles so a family deductible / OOP maximum and household outreach apply correctly, without ever autonomously merging their records. Frontend tests green (3,544 tests — + household-composition three-households / transitive-chain / all-singletons / non-member-link-ignored / member-dedupe / determinism / member+link-echo / min-member-id-ordering plus three-guards-on-produced with phantom-link + household-names-non-member + member-in-two-households + not-all-covered + merged-unlinked-member + wrong-count + wrong-disposition + sourced-vs-consistent-isolation + auto-merged + skipped-review guard cases, the route's envelope / three governance blocks / households-formed + chain + all-singletons happy paths with a PHI-bearing trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to eighty-three agents); the members + links are clearly-labeled illustrative synthetics, NOT a certified enrollment / MDM system — real household / family-unit composition uses the 834 subscriber / dependent structure, address normalization, tax-household rules, and a master-data-management steward's judgment. Lint + build clean.
Agent Fabric: added the Provider Cost & Quality Percentile Benchmarking agent — deterministic percentile / rank statistics (sort + midpoint percentile rank + quartile band) that ranks a provider within a peer cohort's distribution, with the cohort sourced, exact recomputed statistics, and never an autonomous tiering (the 82nd agent)
ShippedDetails
Added the eighty-second agent on the fabric — provider-benchmarking-agent, a DETERMINISTIC (no-Claude) commercial-operations service on the commercial plane, reusing the existing commercial-operations tier as a SIBLING to the Provider Contracting, Pipeline Management, Account Management, and Deal Desk agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: it is NOT the Claim Lifecycle agent's FINITE-STATE-MACHINE TRANSITION VALIDATION, the Medication Name Safety agent's STRING EDIT DISTANCE, the Schedule Conflict agent's GREEDY INTERVAL SELECTION, the Caseload Balancing agent's GREEDY BIN-PACKING, the Access Anomaly agent's SLIDING-WINDOW COUNTING, the Coverage Continuity agent's INTERVAL MERGING, the Care Pathway agent's TOPOLOGICAL ORDERING, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, the Member Cost-Share agent's SEQUENTIAL dollar waterfall, the DDI agent's PAIRWISE KNOWLEDGE-BASE LOOKUP, the OIG Exclusion agent's EXACT identity MATCHING, or the Audit Log Integrity agent's HASH CHAIN, and — crucially — it is NOT the DATE-DEADLINE agents (Timely Filing, Right of Access, Amendment) that add N days to a SINGLE date: the heart of the service is PERCENTILE / RANK STATISTICS over a numeric distribution — sort the cohort, count how many peers fall below / at / above the target, compute the target's midpoint percentile rank, the cohort median, and a quartile band. Provider benchmarking drives value-based-care tiering, incentive payments, and network decisions; a wrong percentile mis-tiers a provider. In a new pure lib/provider-benchmarking.ts, evaluateProviderBenchmarking(request) takes a target provider's metric value plus a peer cohort of providers' values and a metric direction (lower-is-better for cost, higher-is-better for quality), DETERMINISTICALLY computes the percentile rank (the standard midpoint method: (below + 0.5·equal) / n), adjusts for the direction so a higher EFFECTIVE percentile always means better, computes the median, derives a performance band (top-quartile / above-median / below-median / bottom-quartile), and derives the disposition — benchmark-favorable (above-median-or-better) or benchmark-review (below-median, flagged for network review). It COMPLEMENTS, not duplicates, the other provider / quality agents: distinct from the Provider Contracting agent (which computes a single VBC benchmark-DRIFT vs a contract threshold), the HEDIS Quality agent (the measure RATES), the Quality-Measure Attribution agent (the DENOMINATOR), and the Provider Credentialing agent (network integrity) — this ranks a provider within a peer DISTRIBUTION via percentile. TIME IS DATA: the finding is a pure function of the request's own value + cohort + direction (no real clock, no randomness), so the same input always yields the same finding. A finding — benchmark-favorable or benchmark-review — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresNetworkReview:true, autoTiered:false), which is how a legitimate finding is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.benchmark.cohort-sourced (signal benchmarkCohortSourced, violating value false) blocks a finding whose peer cohort is not intact — every cohort member must be a well-formed { providerId, numeric value }, the reported cohort size must equal the actual cohort, and the target value must be numeric, because a phantom or omitted peer silently mis-sizes the denominator and misrepresents the percentile — the sourced gate (mirroring the Claim Lifecycle Agent's states-sourced and the Access Anomaly Agent's events-sourced) — backed by the pure guard benchmarkCohortSourced; policy.benchmark.stats-consistent (signal benchmarkStatsConsistent, violating value false) blocks a finding whose statistics do not add up — recomputing the rank statistics from the echoed cohort (independent of the cohortSize field, so the two gates are isolable) must reproduce the reported counts, percentile rank, direction-adjusted effective percentile, median, performance band, and disposition; a miscomputed / inverted percentile or a band that doesn't follow mis-tiers the provider — this is the load-bearing correctness gate (mirroring the Claim Lifecycle Agent's transition-consistent and the Member Cost-Share Agent's math-consistent) — backed by the guard benchmarkStatsConsistent; and policy.benchmark.no-autonomous-tiering (signal benchmarkNoAutonomousTiering, violating value false) blocks a finding that autonomously tiered the provider, adjusted their payment, or removed them from the network (autoTiered:true — each is a commercially consequential action that must be authorized) or did not require network review (requiresNetworkReview:false) — the agent BENCHMARKS, and every finding is a RECOMMENDATION requiring a network manager to confirm — backed by the guard benchmarkNoAutonomousTiering (mirroring the Provider Contracting Agent's no-autonomous-term-change and the Timely Filing Agent's no-autonomous-write-off posture; the harmful action is enforced-off). It is DELIBERATELY NOT PHI-bearing — it operates on PROVIDER-LEVEL aggregate metrics, not patient health information — so, like the OIG Exclusion agent, it lives on the commercial plane and is NOT on the HIPAA-audit policy; it is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/provider-benchmarking/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — benchmark.receive-metric → benchmark.compute-percentile → benchmark.classify-band → benchmark.log-audit — with NO phiAccessed marker, returning the ProviderBenchmarkingDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Provider Benchmarking panel (a low-cost preset → top-quartile favorable; a high-cost preset → bottom-quartile review with 8 of 9 peers cheaper; a low-quality preset → bottom-quartile review demonstrating the higher-is-better direction inversion; plus mis-sized-cohort / inverted-percentile / auto-tiered governance-block presets), a seeded benchmark.receive-metric→compute-percentile→classify-band→log-audit trace showing the high-cost bottom-quartile case (percentileRank 88.89, effectivePercentile 11.11, requiresNetworkReview:true, NOT PHI), the console subtitle, and the investor brief (now 'eighty-two agents', with the Provider Benchmarking agent on the commercial-operations tier alongside the Provider Contracting and the other commercial agents) all reflect it. Menopause-relevant: a menopause-specialty provider whose risk-adjusted cost-per-episode a payer is about to tier for a value-based-care program is exactly the case where an inverted percentile or a mis-sized peer cohort would wrongly penalize the provider — which this agent surfaces to a network manager without ever tiering. Frontend tests green (3,502 tests — + provider-benchmarking top-quartile / bottom-quartile / direction-inversion / midpoint-equal-values / empty-cohort / determinism / cohort-echo / even-length-median plus three-guards-on-produced with mis-sized-cohort + malformed-member + non-numeric-target + inverted-percentile + wrong-disposition + wrong-median + sourced-vs-consistent-isolation + auto-tiered + skipped-review guard cases, the route's envelope / three governance blocks / favorable + review + quality happy paths with a NOT-PHI trace assertion, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to eighty-two agents); the peer cohorts + metric values are clearly-labeled illustrative synthetics, NOT a certified benchmarking system — real provider benchmarking uses risk / case-mix adjustment, statistically valid peer grouping, minimum denominators, confidence intervals, and the network team's judgment. Lint + build clean.
Agent Fabric: added the Claim Lifecycle / Status-Transition Guard agent — deterministic finite-state-machine transition validation (transition-table lookup + BFS reachability) that decides whether a claim-status move is a legal single step, reachable only via a longer path, or impossible, with every state sourced, exact transition logic, and never an autonomous advance (the 81st agent)
ShippedDetails
Added the eighty-first agent on the fabric — claim-lifecycle-agent, a DETERMINISTIC (no-Claude) claims / payer-operations service on the payer & plan operations plane, reusing the existing payer-operations tier as a SIBLING to the Claims Adjudication Assistant, Coordination of Benefits, Claims Overpayment & Recovery, Timely Filing, and Subrogation agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: it is NOT the Medication Name Safety agent's STRING EDIT DISTANCE, the Schedule Conflict agent's GREEDY INTERVAL SELECTION, the Caseload Balancing agent's GREEDY BIN-PACKING, the Access Anomaly agent's SLIDING-WINDOW COUNTING, the Coverage Continuity agent's INTERVAL MERGING, the Care Pathway agent's TOPOLOGICAL ORDERING (which orders a DAG's nodes — THIS one instead answers reachability + shortest path over a CYCLIC state graph), the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, the Member Cost-Share agent's SEQUENTIAL dollar waterfall, the DDI agent's PAIRWISE KNOWLEDGE-BASE LOOKUP, the OIG Exclusion agent's EXACT identity MATCHING, or the Audit Log Integrity agent's HASH CHAIN, and — crucially — it is NOT the DATE-DEADLINE agents (Timely Filing, Right of Access, Amendment) that add N days to a SINGLE date: the heart of the service is FINITE-STATE-MACHINE TRANSITION VALIDATION — a transition-table lookup (is current → requested a legal edge?) plus a BREADTH-FIRST SEARCH over the state graph (is requested reachable from current, and what is the shortest legal path?). A claim moves through a lifecycle — draft, submitted, acknowledged, adjudicated, paid, denied, appealed, void — and skipping a step (e.g., draft → paid with no adjudication) is a control failure and a leakage / fraud risk. In a new pure lib/claim-lifecycle.ts, evaluateClaimLifecycle(request) takes a claim's current status plus a requested next status and, against a claim-status state machine (states, transitions, terminal states), DETERMINISTICALLY looks up whether current → requested is a legal single-step edge, runs a BFS (shortestTransitionPath, neighbors explored in sorted order for determinism) for reachability + the shortest legal path, and derives the disposition — transition-allowed (a legal single step), transition-illegal-but-reachable (not a single step, but a valid future state — the path shows the required intermediate steps), or transition-unreachable (the target can never follow the current status, e.g., paying a voided claim). It COMPLEMENTS, not duplicates, the other claim agents: distinct from the Claims Adjudication Assistant (per-claim edits), the Coordination of Benefits agent (payer ORDER across coverages), the Claims Overpayment & Recovery agent (POST-payment clawback), the Timely Filing agent (was the claim FILED IN TIME), and the Subrogation agent (third-party liability) — this validates one narrow, purely STRUCTURAL question: is this STATUS TRANSITION legal, and if not, is the target even reachable. TIME IS DATA: the finding is a pure function of the request's own statuses + state machine (no real clock, no randomness), so the same input always yields the same finding. A finding — transition-allowed, transition-illegal-but-reachable, or transition-unreachable — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresAdjusterReview:true, autoAdvanced:false), which is how a legitimate finding is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Medication Name Safety and Care Pathway agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.claim.states-sourced (signal claimStatesSourced, violating value false) blocks a finding that names a status — in the allowed-next set or in the shortest path — that is not a defined state of the machine, or a path step that is not a real transition, because a fabricated state invents a lifecycle stage that doesn't exist and a fabricated edge invents a legal move that isn't allowed — the sourced gate (mirroring the Care Pathway Agent's steps-sourced and the Medication Name Safety Agent's candidates-sourced) — backed by the pure guard claimStatesSourced; policy.claim.transition-consistent (signal claimTransitionConsistent, violating value false) blocks a finding whose transition logic does not add up — recomputing the transition table + the BFS from the machine must reproduce the reported direct-edge flag, the reachability flag, the allowed-next set, the shortest-path length + endpoints, and the disposition; a wrong direct-edge flag would wave through an illegal transition (skipping adjudication) or block a legal one, a wrong reachability / path would misroute the claim — this is the load-bearing correctness gate, and it recomputes from the machine using the path ENDPOINTS (leaving interior-edge sourcing to the states-sourced guard, so the two gates are independent and isolable) (mirroring the Care Pathway Agent's sequence-valid and the Medication Name Safety Agent's distances-consistent) — backed by the guard claimTransitionConsistent; and policy.claim.no-autonomous-advance (signal claimNoAutonomousAdvance, violating value false) blocks a finding that autonomously advanced the claim, posted a payment, or finalized a denial (autoAdvanced:true — each is a payer action that must be authorized) or did not require adjuster review (requiresAdjusterReview:false) — the agent VALIDATES, and every finding is a RECOMMENDATION requiring an adjuster to confirm the transition — backed by the guard claimNoAutonomousAdvance (mirroring the Timely Filing Agent's no-autonomous-write-off and the Overpayment Recovery Agent's no-autonomous-clawback posture; the harmful action is enforced-off). It IS PHI-bearing — the claim references a patient — so it reuses, by extending appliesTo, the HIPAA-audit policy (phiAccessed:true throughout), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/claim-lifecycle/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — claim.receive-transition → claim.check-transition → claim.compute-reachability → claim.log-audit — with phiAccessed:true, returning the ClaimLifecycleDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Claim Lifecycle panel (an 'adjudicated → paid' preset → transition-allowed; a 'draft → paid' preset → illegal-but-reachable in 4 steps with the BFS path shown; a 'void → paid' preset → unreachable; plus fabricated-state / wrong-direct-edge / auto-advanced governance-block presets), a seeded claim.receive-transition→check-transition→compute-reachability→log-audit trace showing the draft→paid illegal-but-reachable case (directEdge false, pathLength 4, requiresAdjusterReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'eighty-one agents', with the Claim Lifecycle agent on the payer-operations tier alongside the Timely Filing and the other claim agents) all reflect it. Menopause-relevant: a 45-64 patient's menopause-care claim that a downstream automation tries to push straight from draft to paid — skipping acknowledgement and adjudication — is exactly the control failure this state-machine guard catches and routes to an adjuster, without ever advancing the claim itself. Frontend tests green (3,461 tests — + claim-lifecycle allowed / illegal-but-reachable / unreachable / unknown-status / determinism / machine-echo plus shortestTransitionPath unit tests and three-guards-on-produced with fabricated-state + wrong-direct-edge + wrong-path-length + wrong-disposition + sourced-vs-consistent-isolation + auto-advanced + skipped-review guard cases, the route's envelope / three governance blocks / allowed + illegal + unreachable happy paths, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to eighty-one agents); the claim-status state machine is a clearly-labeled illustrative synthetic, NOT a certified claims-processing system — real claim-status management uses the X12 277 claim-status category / status codes, the payer's adjudication system, and the plan's business rules. Lint + build clean.
Agent Fabric: added the Medication Name Safety (LASA) agent — deterministic Levenshtein edit-distance matching that flags look-alike / sound-alike drug-name confusion against a formulary catalog, with every candidate sourced from the catalog, exact recomputed distances, and never an autonomous substitution (the 80th agent)
ShippedDetails
Added the eightieth agent on the fabric — medication-name-safety-agent, a DETERMINISTIC (no-Claude) clinical-decision service on the patient / clinical plane, reusing the existing clinical-decision tier as a SIBLING to the Drug–Drug Interaction, Controlled Substance / PDMP, Formulary & DUR Review, Care Pathway, and Lab Result agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: it is NOT the Schedule Conflict agent's GREEDY INTERVAL SELECTION, the Caseload Balancing agent's GREEDY BIN-PACKING, the Access Anomaly agent's SLIDING-WINDOW COUNTING, the Coverage Continuity agent's INTERVAL MERGING, the Care Pathway agent's TOPOLOGICAL ORDERING, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, the Member Cost-Share agent's SEQUENTIAL dollar waterfall, the Drug–Drug Interaction agent's PAIRWISE KNOWLEDGE-BASE LOOKUP, the OIG Exclusion agent's EXACT identity MATCHING (which explicitly does NO fuzzy / phonetic matching), or the Audit Log Integrity agent's HASH CHAIN, and — crucially — it is NOT the DATE-DEADLINE agents (Timely Filing, Right of Access, Amendment) that add N days to a SINGLE date: the heart of the service is STRING EDIT DISTANCE (the classic Levenshtein dynamic-programming algorithm — the minimum single-character insertions, deletions, and substitutions to turn one name into another). Look-alike / sound-alike (LASA) medication-name confusion (premarin vs primaxin, hydroxyzine vs hydralazine) is one of the most persistent sources of medication error — the ISMP maintains a LASA list and the Joint Commission requires organizations to manage it. In a new pure lib/medication-name-safety.ts, evaluateMedicationNameSafety(request) takes a prescribed / typed drug name plus a formulary catalog and a confusability threshold, DETERMINISTICALLY normalizes the name (lowercase / trim / collapse whitespace), computes the Levenshtein distance to every catalog drug, finds the nearest match, collects the look-alikes within the threshold (0 < distance ≤ threshold — near but not an exact match), and derives the disposition — recognized-clear (an exact match with no look-alike), lasa-warning (a look-alike within the threshold — a possible wrong-drug confusion or near-miss misspelling), or unrecognized (no exact match and nothing within the threshold). It COMPLEMENTS, not duplicates, the other medication agents: distinct from the Drug–Drug Interaction agent (whether two drugs INTERACT), the Formulary & DUR agent (whether a drug is COVERED / appropriate), the Controlled-Substance / PDMP agent (opioid MME safety), and the Medication Adherence agent (refill nudges) — this catches a name CONFUSABLE with a DIFFERENT drug before it becomes a wrong-drug error. TIME IS DATA: the finding is a pure function of the request's own name + catalog + threshold (no real clock, no randomness), so the same input always yields the same finding. A finding — recognized-clear, lasa-warning, or unrecognized — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresPharmacistReview:true, autoSubstituted:false), which is how a legitimate finding is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Schedule Conflict and Caseload Balancing agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.lasa.candidates-sourced (signal lasaCandidatesSourced, violating value false) blocks a finding that names a candidate — the nearest match or a confusable look-alike — not backed by the catalog (its drugId must be in the catalog and its echoed name must equal that drug's catalog name), because a fabricated candidate invents a look-alike that doesn't exist and a mislabeled one attaches the wrong name — the sourced gate (mirroring the Drug–Drug Interaction Agent's interaction-sourced and the Schedule Conflict Agent's intervals-sourced) — backed by the pure guard lasaCandidatesSourced; policy.lasa.distances-consistent (signal lasaDistancesConsistent, violating value false) blocks a finding whose edit distances do not add up — recomputing the Levenshtein distances from the echoed catalog (using the catalog names, so this gate is independent of the sourced check) must reproduce the reported nearest match, every distance, the exact-match flag, the confusable set (exactly those within the threshold), and the disposition; a miscomputed distance, a wrong nearest match, an omitted or spurious look-alike, or a disposition that doesn't follow drives a wrong finding — this is the load-bearing correctness gate (mirroring the Schedule Conflict Agent's conflict-free and the Access Anomaly Agent's window-count-consistent) — backed by the guard lasaDistancesConsistent; and policy.lasa.no-autonomous-substitution (signal lasaNoAutonomousSubstitution, violating value false) blocks a finding that autonomously substituted, corrected, or dispensed a drug (autoSubstituted:true — each is a clinical action that must be authorized) or did not require pharmacist review (requiresPharmacistReview:false) — the agent FLAGS, and every finding is a RECOMMENDATION requiring a pharmacist to confirm the intended medication — backed by the guard lasaNoAutonomousSubstitution (mirroring the Drug–Drug Interaction Agent's no-autonomous-hold-or-override and the Schedule Conflict Agent's no-autonomous-booking posture; the harmful action is enforced-off). It IS PHI-bearing — the prescribed name is for a patient's medication order — so it reuses, by extending appliesTo, the HIPAA-audit policy (phiAccessed:true throughout), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/medication-name-safety/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — lasa.receive-name → lasa.compute-distances → lasa.flag-lookalike → lasa.log-audit — with phiAccessed:true, returning the MedicationNameSafetyDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Medication Name Safety panel (a 'gabapentin' preset → recognized-clear; a 'premarin' preset → lasa-warning against the look-alike primaxin at edit distance 2; a 'trelagliptin' preset → unrecognized; plus fabricated-candidate / wrong-disposition / auto-substituted governance-block presets), a seeded lasa.receive-name→compute-distances→flag-lookalike→log-audit trace showing the premarin LASA case (nearest premarin distance 0, look-alike primaxin distance 2, requiresPharmacistReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'eighty agents', with the Medication Name Safety agent on the clinical-decision tier alongside the Drug–Drug Interaction and the other clinical agents) all reflect it. Menopause-relevant: a hurried order for 'premarin' (conjugated estrogens for menopausal symptoms) that is two keystrokes from 'primaxin' (an IV antibiotic) is exactly the wrong-drug confusion this edit-distance check surfaces for a pharmacist — without ever autonomously changing the order. Frontend tests green (3,419 tests — + medication-name-safety recognized-clear / lasa-warning-exact-plus-lookalike / near-miss-misspelling / unrecognized / custom-threshold / determinism / catalog-echo plus levenshtein + normalize unit tests and three-guards-on-produced with fabricated-candidate + mislabeled-candidate + wrong-disposition + wrong-distance + omitted-lookalike + sourced-vs-consistent-isolation + auto-substituted + skipped-review guard cases, the route's envelope / three governance blocks / clear + lasa + unrecognized happy paths, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to eighty agents); the formulary catalog + names are clearly-labeled illustrative synthetics, NOT a certified medication-safety system — real LASA safety uses the ISMP / FDA LASA lists, tall-man lettering, RxNorm / First Databank vocabularies, indication / dose context, and barcode scanning. Lint + build clean.
Agent Fabric: added the Scheduling Conflict / Double-Booking Guard agent — deterministic greedy interval selection (activity-selection) that computes a resource's maximum conflict-free schedule and waitlists the collisions, with every appointment sourced and accounted for once, a conflict-free (no double-booking) schedule, and never an autonomous booking (the 79th agent)
ShippedDetails
Added the seventy-ninth agent on the fabric — schedule-conflict-agent, a DETERMINISTIC (no-Claude) care-coordination service on the patient / clinical plane, reusing the existing care-coordination tier as a SIBLING to the Appointment Scheduling, Caseload Balancing, Care Team & Case Management, Transitions of Care, and Population Health agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: it is NOT the Caseload Balancing agent's GREEDY BIN-PACKING under a capacity constraint, the Access Anomaly agent's SLIDING-WINDOW COUNTING, the Coverage Continuity agent's INTERVAL MERGING + GAP DETECTION (that one MERGES overlapping intervals into continuous spans; THIS one SELECTS a maximum NON-overlapping subset), the Care Pathway agent's TOPOLOGICAL ORDERING, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, the Member Cost-Share agent's SEQUENTIAL dollar waterfall, the OIG Exclusion agent's identity MATCHING, or the Audit Log Integrity agent's HASH CHAIN, and — crucially — it is NOT the DATE-DEADLINE agents (Timely Filing, Right of Access, Amendment) that add N days to a SINGLE date: the heart of the service is GREEDY INTERVAL SELECTION (the classic activity-selection algorithm: sort the requested intervals by EARLIEST FINISH time and admit each one that does not overlap the last admitted, provably maximizing the number of non-overlapping appointments). Double-booking a provider, a room, or an infusion chair is a real operational failure mode; this agent guards a whole batch of requests for one resource. In a new pure lib/schedule-conflict.ts, evaluateScheduleConflict(request) takes a resource plus a batch of requested appointment intervals (each a start/end time for a patient — ISO strings or epoch-ms), validates them (parseable start < end, unique id), DETERMINISTICALLY sorts by earliest finish (ties by start, then id), runs the two-pointer activity-selection greedy to admit the maximum conflict-free set, and WAITLISTS each request that overlaps the last admitted (recording which scheduled appointment it conflicts with) — reporting the disposition (conflict-free or conflicts-waitlisted), the scheduled appointments, and the waitlist. It COMPLEMENTS, not duplicates, the Appointment Scheduling agent (which BOOKS a SINGLE slot against a provider calendar and never double-books THAT slot): this validates a WHOLE BATCH for a resource, computes the conflict-free schedule + the waitlist, and hands it to a scheduler — the double-booking guard for a day, not the booker of one appointment. TIME IS DATA: the schedule is a pure function of the request's own intervals (times accepted as data, no real clock), so the same batch always yields the same schedule, and the greedy MAXIMIZES the number scheduled (two short appointments beat one long one) rather than 'first request wins'. A schedule — fully conflict-free OR partial with a waitlist — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresSchedulerReview:true, autoBooked:false), which is how a legitimate schedule is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Caseload Balancing and Coverage Continuity agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.schedule.intervals-sourced (signal scheduleIntervalsSourced, violating value false) blocks a determination whose appointments do not trace to submitted requests or do not account for every request exactly once — every scheduled / waitlisted appointment's id, member, start, and end must match a submitted interval, and the scheduled set and the conflict set must be disjoint and cover every request (no fabricated appointment, no dropped patient, no double-count) — the sourced + completeness gate (mirroring the Caseload Balancing Agent's assignment-complete and the Coverage Continuity Agent's segments-sourced) — backed by the pure guard scheduleIntervalsSourced; policy.schedule.conflict-free (signal scheduleConflictFree, violating value false) blocks a determination that is not conflict-free — the scheduled appointments must be pairwise NON-overlapping (no double-booking), every waitlisted appointment must genuinely overlap the scheduled appointment named in its conflictsWith, and the counts must add up; the guard recomputes every pairwise overlap and re-checks each waitlist justification (this is the load-bearing correctness gate, mirroring the Caseload Balancing Agent's capacity-respected and the Access Anomaly Agent's window-count-consistent) — backed by the guard scheduleConflictFree; and policy.schedule.no-autonomous-booking (signal scheduleNoAutonomousBooking, violating value false) blocks a determination that autonomously booked, cancelled, or bumped an appointment (autoBooked:true — each is a scheduling action that must be authorized) or did not require scheduler review (requiresSchedulerReview:false) — the agent RECOMMENDS, and every schedule is a RECOMMENDATION requiring a scheduler to confirm — backed by the guard scheduleNoAutonomousBooking (mirroring the Caseload Balancing Agent's no-autonomous-assignment and the Appointment Scheduling Agent's governance posture; the harmful action is enforced-off). It IS PHI-bearing — the requests reference the patients being scheduled — so it reuses, by extending appliesTo, the HIPAA-audit policy (phiAccessed:true throughout), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/schedule-conflict/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — schedule.receive-requests → schedule.select-intervals → schedule.check-conflicts → schedule.log-audit — with phiAccessed:true, returning the ScheduleConflictDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Scheduling Conflict panel (a 3-spaced-requests preset → conflict-free; an overlapping-requests preset → partial with a waitlist; a maximize preset → two short appointments admitted over one long one, proving the greedy MAXIMIZES; plus fabricated-appointment / double-booked / auto-booked governance-block presets), a seeded schedule.receive-requests→select-intervals→check-conflicts→log-audit trace showing the waitlist case (2 of 4 scheduled conflict-free, 2 waitlisted, requiresSchedulerReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'seventy-nine agents', with the Scheduling Conflict agent on the care-coordination tier alongside the Appointment Scheduling and the other care-coordination agents) all reflect it. Menopause-relevant: a busy menopause-specialist clinic day where four midlife women request overlapping visit windows is exactly where a double-booking guard picks the maximum conflict-free set and surfaces the rest for rescheduling — without ever autonomously booking or bumping a patient. Frontend tests green (3,373 tests — + schedule-conflict conflict-free / waitlist-earliest-finish / maximize-two-over-one / invalid-skip / determinism / three-guards-on-produced plus fabricated-appointment + altered-attribution + dropped-request + double-booked + unjust-waitlist + phantom-conflictsWith guard cases, the route's envelope / three governance blocks / conflict-free + waitlist + maximize happy paths, the panel's presets / request-body / view-lift / hhmm, and the registry + brief drift guards raised to seventy-nine agents); the resource + intervals are clearly-labeled illustrative synthetics, NOT a certified scheduling system — real scheduling uses provider availability calendars, appointment-type durations, buffer / turnover times, and room / equipment constraints. Lint + build clean.
Agent Fabric: added the Caseload Balancing (Care-Manager Panel Assignment) agent — deterministic greedy bin-packing that allocates a panel of members across care managers within capacity, waitlisting the overflow, with every member accounted for exactly once, no manager over capacity, and never an autonomous assignment (the 78th agent)
ShippedDetails
Added the seventy-eighth agent on the fabric — caseload-balancing-agent, a DETERMINISTIC (no-Claude) care-coordination service on the patient / clinical plane, reusing the existing care-coordination tier as a SIBLING to the Care Team & Case Management, Complex Care Management, Transitions of Care, Care Coordination Handoff, and Population Health agents — it does NOT invent a new tier or plane, and it RETURNS TO THE PATIENT / CLINICAL plane after the platform Access Anomaly agent. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: it is NOT the Access Anomaly agent's SLIDING-WINDOW COUNTING, the Coverage Continuity agent's INTERVAL MERGING + GAP DETECTION, the Care Pathway agent's TOPOLOGICAL ORDERING, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, the Member Cost-Share agent's SEQUENTIAL dollar waterfall, the OIG Exclusion agent's identity MATCHING, or the Audit Log Integrity agent's HASH CHAIN, and — crucially — it is NOT the DATE-DEADLINE agents (Timely Filing, Right of Access, Amendment) that add N days to a SINGLE date: the heart of the service is GREEDY ALLOCATION UNDER A CAPACITY CONSTRAINT (a bin-packing / worst-fit-decreasing assignment of weighted items into capacity-limited bins). A care manager's 'panel' is the set of patients they actively manage; each patient carries an acuity (how much attention they need), and each manager has a finite capacity — over-loading a panel is a patient-safety risk, so the allocation must respect capacity and surface the overflow rather than silently drop it. In a new pure lib/caseload-balancing.ts, evaluateCaseloadBalancing(request) takes a panel of members (each with an acuity weight) and a set of care managers (each with a weighted-slot capacity), validates them (positive-integer acuity; non-negative-integer capacity, unique manager id), and DETERMINISTICALLY runs a worst-fit-decreasing greedy bin-packing: it processes members in DESCENDING acuity (ties by member id) and, for each, places it into the manager with the GREATEST remaining capacity that can still fit it (remaining ≥ acuity; ties by manager id) — spreading load evenly — or WAITLISTS it when no manager has room, reporting the disposition (fully-assigned or partially-assigned-waitlist), the per-manager loads, and the waitlist. It COMPLEMENTS, not duplicates, the other care-coordination agents: distinct from the Care Team & Case Management agent (which assembles the multi-disciplinary team around ONE patient and picks that patient's case manager), the Complex Care Management agent (CCM time-tracking + billing for ONE patient), the Transitions of Care agent (moving ONE patient between settings), and the Population Health agent (which PRIORITIZES / stratifies a panel) — this ALLOCATES a whole panel across the managers' finite capacity, the balancing of caseloads. TIME IS DATA: the allocation is a pure function of the request's own members + managers (no real clock), so the same panel always yields the same assignment. An allocation — fully assigned OR partially assigned with a waitlist — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresCareLeadReview:true, autoAssigned:false), which is how a legitimate allocation is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Access Anomaly and Coverage Continuity agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.caseload.assignment-complete (signal caseloadAssignmentComplete, violating value false) blocks a determination that does not account for EVERY member EXACTLY once — the assigned set and the waitlisted set must be disjoint and together cover every submitted member (no dropped member, no double-assignment), and the reported counts must match; a dropped member is a patient who falls through the cracks with no manager owning their care, a double-assigned member is confused ownership — this is the completeness gate (mirroring the Enrollment Reconciliation Agent's reconciliation-complete and the Accounting of Disclosures Agent's accountable-disclosures-complete) — backed by the pure guard caseloadAssignmentComplete; policy.caseload.capacity-respected (signal caseloadCapacityRespected, violating value false) blocks a determination that violates capacity — each manager's assigned acuity must equal the sum of their assigned members' acuities, must not exceed their capacity, and the remaining capacity must be exact, and every waitlisted member's acuity must exceed EVERY manager's final remaining capacity (a member waitlisted while a manager had room is a wrong, unsafe allocation); the guard recomputes each manager's load from the assignments, checks it against capacity, and verifies every waitlist is justified (this is the load-bearing correctness gate, mirroring the Access Anomaly Agent's window-count-consistent and the Member Cost-Share Agent's math-consistent) — backed by the guard caseloadCapacityRespected; and policy.caseload.no-autonomous-assignment (signal caseloadNoAutonomousAssignment, violating value false) blocks a determination that autonomously committed an assignment (autoAssigned:true — committing an assignment, reassigning a patient, or overriding a manager's caseload is a care-ownership decision that must be authorized) or did not require care-lead review (requiresCareLeadReview:false) — the agent RECOMMENDS, and every allocation is a RECOMMENDATION requiring a care-management lead to confirm — backed by the guard caseloadNoAutonomousAssignment (mirroring the Care Team Agent's no-autonomous-assignment and the Coverage Continuity Agent's no-autonomous-determination posture; the harmful action is enforced-off). It IS PHI-bearing — the members reference the patients on the panel — so it reuses, by extending appliesTo, the HIPAA-audit policy (phiAccessed:true throughout), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/caseload-balancing/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — caseload.receive-panel → caseload.allocate → caseload.check-capacity → caseload.log-audit — with phiAccessed:true, returning the CaseloadBalancingDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Caseload Balancing panel (a 6-member / 3-manager preset → fully assigned within capacity; an over-capacity preset → partially assigned with a waitlist; an equal-members preset → evenly balanced 2-and-2; plus dropped-member / over-capacity / auto-assigned governance-block presets), a seeded caseload.receive-panel→allocate→check-capacity→log-audit trace showing the fully-assigned case (6 members across 3 managers, assigned acuity 21 of 24, requiresCareLeadReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'seventy-eight agents', with the Caseload Balancing agent on the care-coordination tier alongside the Care Team and the other care-coordination agents) all reflect it. Menopause-relevant: a care-management program for 45-64 women with high-acuity midlife needs — complex perimenopausal symptoms, cardiovascular and bone-health risk, behavioral health — is exactly the kind of panel this balances across a finite set of nurse care managers so no manager is over-loaded and no patient is left without an owner. Frontend tests green (3,332 tests — + caseload full-assign / waitlist-overflow / even-balance / accounted-once / invalid-skip / no-managers / determinism / three-signal-true-and-false guards including over-capacity + miscounted-load + unjust-waitlist + acuity-mismatch, the route's envelope / three governance blocks / full + waitlist + balanced happy paths, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to seventy-eight agents); the members + managers + acuity + capacity are clearly-labeled illustrative synthetics, NOT a certified caseload / staffing system — real panel assignment uses validated acuity instruments, care-manager licensure / specialty / language fit, geographic match, and continuity of an existing relationship. Lint + build clean.
Agent Fabric: added the Access Anomaly Detection agent — deterministic sliding-window counting of an actor's PHI-access events, flagging an anomalous access volume when the peak in any rolling window exceeds the threshold (HIPAA §164.308 information-system activity review), with every counted access sourced, an exact window count, and never an autonomous access action (the 77th agent)
ShippedDetails
Added the seventy-seventh agent on the fabric — access-anomaly-agent, a DETERMINISTIC (no-Claude) control-plane / data-substrate service on the platform & data substrate plane, reusing the existing data-plane tier as a SIBLING to the Audit Log Integrity, Accounting of Disclosures, Break-the-Glass, Minimum Necessary, De-Identification, Consent, Master Patient Index, Records Retention, Right of Access, Amendment, and Information Blocking agents — it does NOT invent a new tier or plane, and it RETURNS TO THE PLATFORM plane after the payer Creditable Coverage Continuity agent. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: it is NOT the Coverage Continuity agent's INTERVAL MERGING + GAP DETECTION, the Care Pathway agent's TOPOLOGICAL ORDERING, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, the Member Cost-Share agent's SEQUENTIAL dollar waterfall, the OIG Exclusion agent's identity MATCHING, or the Audit Log Integrity agent's HASH CHAIN, and — crucially — it is NOT the DATE-DEADLINE agents (Timely Filing, Right of Access, Amendment) that add N days to a SINGLE date: the heart of the service is SLIDING-WINDOW COUNTING over timestamped events (a two-pointer scan for the peak count in any window of a fixed length). The HIPAA Security Rule's information-system-activity-review safeguard (§164.308(a)(1)(ii)(D)) requires covered entities to regularly review records of information-system activity such as audit logs and access reports; an unusual VOLUME of PHI accesses by one workforce member in a short window is a classic snooping / breach indicator. In a new pure lib/access-anomaly.ts, evaluateAccessAnomaly(request) takes an actor's PHI-access events (each a timestamped read of a patient record) plus a window length and a threshold, DETERMINISTICALLY parses the timestamps to epoch-ms, sorts them, runs a two-pointer sliding-window scan to find the PEAK number of accesses in any window of the configured length, and flags an ANOMALOUS ACCESS VOLUME when that peak exceeds the threshold — reporting the peak window (its span, count, distinct patients, and event ids). It COMPLEMENTS, not duplicates, the other platform agents: distinct from the Audit Log Integrity agent (whether the audit TRAIL is tamper-evident), the Break-the-Glass agent (whether a SINGLE emergency access is authorized), the Minimum Necessary agent (how much PHI a purpose may see), the Accounting of Disclosures agent (WHO a patient's PHI was disclosed to), and the Consent agent (whether a patient may be contacted / data used) — this detects an unusual VOLUME of accesses by one actor OVER TIME. TIME IS DATA: the analysis is a pure function of the request's own events + window + threshold (no real clock), so the same events always yield the same peak + finding, and the detection is WINDOWED (a high daily total spread into small bursts is NOT flagged), not a naive total count. A finding — normal activity OR an anomalous spike — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresPrivacyReview:true, autoLockedAccount:false, autoRevokedAccess:false), which is how a legitimate finding is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Coverage Continuity and Audit Log Integrity agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.access.events-sourced (signal accessEventsSourced, violating value false) blocks a finding whose peak window does not trace to submitted access events — the peak window's event ids must be a subset of the submitted events and its count must equal the number of those ids, because a fabricated access (an event in the peak not backed by a submitted one) would manufacture a false anomaly and a phantom count would overstate the spike — backed by the pure guard accessEventsSourced (mirroring the Coverage Continuity Agent's segments-sourced and the Audit Log Integrity Agent's hash-chain-verified posture); policy.access.window-count-consistent (signal accessWindowCountConsistent, violating value false) blocks a finding whose window count does not add up — recomputing the sliding-window peak from the events must reproduce the reported peak count, the peak window's events must all fall within a span of at most windowMinutes, and the anomaly flag must equal whether the peak exceeds the threshold; the guard recomputes the peak, checks the window span, and re-derives the flag (this is the load-bearing correctness gate, mirroring the Coverage Continuity Agent's math-consistent and the Audit Log Integrity Agent's sequence-complete) — backed by the guard accessWindowCountConsistent; and policy.access.no-autonomous-action (signal accessNoAutonomousAction, violating value false) blocks a finding that autonomously took an access / employment action (autoLockedAccount:true or autoRevokedAccess:true — locking an account, revoking access, or disciplining a workforce member is an action that must be authorized) or did not require privacy review (requiresPrivacyReview:false) — the agent MEASURES, and every flag is a RECOMMENDATION requiring a privacy officer to review — backed by the guard accessNoAutonomousAction (mirroring the Coverage Continuity Agent's no-autonomous-determination and the Audit Log Integrity Agent's no-autonomous-redaction posture; the harmful action is enforced-off). It IS PHI-bearing — the events reference the patients whose records were accessed — so it reuses, by extending appliesTo, the HIPAA-audit policy (phiAccessed:true throughout), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/access-anomaly/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — access.receive-events → access.scan-window → access.flag-anomaly → access.log-audit — with phiAccessed:true, returning the AccessAnomalyDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Access Anomaly panel (a 24-accesses-in-46-minutes preset → anomalous over the 20-in-60-minutes threshold; a spread-out-access preset → normal; a high-total-small-bursts preset → normal, proving the detection is WINDOWED not a total count; plus fabricated-peak / mismatched-flag / auto-locked-account governance-block presets), a seeded access.receive-events→scan-window→flag-anomaly→log-audit trace showing the anomalous case (peak 24 in a 60-minute window across 24 distinct patients, requiresPrivacyReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'seventy-seven agents', with the Access Anomaly agent on the data-plane tier alongside the Audit Log Integrity and the other platform agents) all reflect it. Menopause-relevant: a 45-64 woman's menopause care record being viewed 24 times in under an hour by a single non-treating staff member is exactly the snooping pattern this activity review flags for a privacy officer — without ever autonomously locking the account. Frontend tests green (3,294 tests — + access-anomaly window-boundary-inclusive / just-outside-window-excluded / windowed-not-total / empty-set / invalid-timestamp-skip / defaults / determinism / three-signal-true-and-false guards, the route's envelope / three governance blocks / anomalous + normal + burst happy paths, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to seventy-seven agents); the events + window + threshold are clearly-labeled illustrative synthetics, NOT a certified breach-detection / SIEM system — real activity review uses the full audit trail, user-behavior analytics, role / relationship context, and the privacy officer's judgment. Lint + build clean.
Agent Fabric: added the Creditable Coverage Continuity agent — deterministic interval-merge + gap-detection over a member's coverage segments, flagging a significant break (>63-day gap) in creditable coverage, with every merged span sourced, exact coverage math, and never an autonomous coverage determination (the 76th agent)
ShippedDetails
Added the seventy-sixth agent on the fabric — coverage-continuity-agent, a DETERMINISTIC (no-Claude) claims / payer-operations service on the payer & plan operations plane, reusing the existing payer-operations tier as a SIBLING to the Benefits Verification, Coordination of Benefits, Enrollment Reconciliation, Member Cost-Share, MLR Rebate, Claims Adjudication, and OIG Exclusion agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: it is NOT the Care Pathway agent's TOPOLOGICAL ORDERING, the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, the Member Cost-Share agent's SEQUENTIAL dollar waterfall, the OIG Exclusion agent's identity MATCHING, or the MLR Rebate agent's RATIO + apportionment, and — crucially — it is NOT the DATE-DEADLINE agents (Timely Filing, Right of Access, Amendment) that add N days to a SINGLE date: the heart of the service is INTERVAL MERGING + GAP DETECTION over a set of date ranges. 'Creditable coverage' is prior health coverage that counts toward waiting-period / pre-existing-condition rules; a break longer than 63 days (a 'significant break') resets it and can trigger a special-enrollment loss or a Medicare Part D late-enrollment penalty. In a new pure lib/coverage-continuity.ts, evaluateCoverageContinuity(request) takes a member's coverage segments (each a start/end date from an employer, individual, or public plan) and DETERMINISTICALLY sorts them, MERGES the overlapping / adjacent ones into continuous spans (a gap of 0 days — the next starts the day after the previous ends — still merges), totals the inclusive covered days, measures the GAPS between consecutive spans, and flags a SIGNIFICANT BREAK when a gap exceeds the threshold (63 days by the HIPAA / ACA rule, DEFAULT_MAX_GAP_DAYS). It COMPLEMENTS, not duplicates, the other payer-operations agents: distinct from the Benefits Verification agent (is coverage active NOW), the Coordination of Benefits agent (the ORDER of concurrent coverages), the Enrollment Reconciliation agent (employer-vs-carrier roster drift), the Member Cost-Share agent (splitting a claim), and the MLR Rebate agent (a plan-year rebate) — this measures the CONTINUITY of a member's coverage OVER TIME. TIME IS DATA: the analysis is a pure function of the segments + the request's own asOfDate (no real clock; all interval math via UTC epoch-day integers), so the same segments always yield the same spans + gaps + determination. A determination — continuous coverage OR a significant break — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresEligibilityReview:true, autoDetermined:false), which is how a legitimate determination is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Enrollment Reconciliation and MLR Rebate agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.coverage.segments-sourced (signal coverageSegmentsSourced, violating value false) blocks a determination whose merged span does not trace to submitted segments — each span's start / end must come from a real segment boundary and every submitted segment must fall within a merged span, because fabricated coverage (a span not backed by a segment) would wrongly certify continuity and dropped coverage would wrongly find a break — backed by the pure guard coverageSegmentsSourced (mirroring the Care Pathway Agent's steps-sourced and the Drug Interaction Agent's interaction-sourced posture); policy.coverage.math-consistent (signal coverageMathConsistent, violating value false) blocks a determination whose math does not add up — the merged spans must be ordered + non-overlapping (each start ≤ end, strictly gapped from the previous), the total covered days must equal the sum of the spans' inclusive lengths, each reported gap must equal the exact day distance between consecutive spans, and the significant-break flag must equal whether any gap exceeds the threshold; the guard recomputes the totals, the gaps, and the break flag from the spans (this is the load-bearing correctness gate, mirroring the Member Cost-Share Agent's math-consistent and the MLR Rebate Agent's allocation-consistent) — backed by the guard coverageMathConsistent; and policy.coverage.no-autonomous-determination (signal coverageNoAutonomousDetermination, violating value false) blocks a determination that autonomously issued a creditable-coverage determination (autoDetermined:true — issuing a determination, denying special enrollment, or imposing a late-enrollment penalty is a coverage decision that must be authorized) or did not require eligibility review (requiresEligibilityReview:false) — the agent MEASURES, and every determination is a RECOMMENDATION requiring an eligibility reviewer to confirm — backed by the guard coverageNoAutonomousDetermination (mirroring the Enrollment Reconciliation Agent's no-autonomous-change and the MLR Rebate Agent's no-autonomous-disbursement posture; the harmful action is enforced-off). It IS PHI-bearing — the segments reference the member's coverage history — so it reuses, by extending appliesTo, the HIPAA-audit policy (phiAccessed:true throughout), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/coverage-continuity/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — coverage.receive-segments → coverage.merge-intervals → coverage.detect-gaps → coverage.log-audit — with phiAccessed:true, returning the CoverageContinuityDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Coverage Continuity panel (a 14-day-gap preset → continuous; a 153-day-gap preset → significant break; an overlapping-coverage preset → merged into a single continuous span with no gaps; plus fabricated-span / miscounted-math / auto-determined governance-block presets), a seeded coverage.receive-segments→merge-intervals→detect-gaps→log-audit trace showing the continuous case (352 covered days across 2 spans, requiresEligibilityReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'seventy-six agents', with the Coverage Continuity agent on the payer-operations tier alongside the Enrollment Reconciliation and the other payer agents) all reflect it. Menopause-relevant: a 45-64 woman who leaves an employer plan and has a 2-month gap before her individual-market coverage begins is exactly the case this checks — a 14-day gap keeps her creditable coverage intact, but a break over 63 days would cost her the pre-existing-condition protection she needs for ongoing menopause care. Frontend tests green (3,251 tests — + coverage date-helper round-trip / continuous-under-threshold / significant-break / overlap-merge / adjacent-merge / invalid-segment-skip / custom-threshold / determinism / three-signal-true-and-false guards, the route's envelope / three governance blocks / continuous + break + overlap happy paths, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to seventy-six agents); the segments + threshold are clearly-labeled illustrative synthetics, NOT a certified creditable-coverage system — real determination uses the certificate of creditable coverage, plan-specific rules, and the full HIPAA / ACA / Medicare Part D frameworks. Lint + build clean.
Agent Fabric: added the Care Pathway Sequencing agent — deterministic topological ordering (Kahn's algorithm) of a clinical pathway's steps to respect their prerequisite dependencies, detecting dependency cycles and missing prerequisites, with every step sourced, an order that never violates a prerequisite, and never an autonomous step execution (the 75th agent)
ShippedDetails
Added the seventy-fifth agent on the fabric — care-pathway-agent, a DETERMINISTIC (no-Claude) clinical-decision service on the patient / clinical plane, reusing the existing clinical-decision tier as a SIBLING to the Care Plan, Drug Interaction, Controlled Substance / PDMP, Formulary & DUR, Medication Adherence, Prior Authorization, Immunization, and Lab Result agents — it does NOT invent a new tier or plane, and it is a RETURN TO THE PATIENT / CLINICAL PLANE after two payer-operations agents (Member Cost-Share, MLR Rebate, Enrollment Reconciliation). It is DELIBERATELY a DIFFERENT KIND of logic — a genuinely NEW computation pattern for the fabric: there is NO date math (unlike the Amendment / Right of Access / Timely Filing agents), NO dollar waterfall (unlike the Member Cost-Share agent), NO single-record classifier (unlike the Information Blocking agent), NO pairwise lookup (unlike the Drug Interaction agent), and — crucially — it is NOT the Enrollment Reconciliation agent's KEYED SET-DIFFERENCE, the OIG Exclusion agent's identity MATCHING, or the MLR Rebate agent's RATIO + apportionment: the heart of the service is a TOPOLOGICAL ORDERING (Kahn's algorithm) over a dependency graph + CYCLE DETECTION. A clinical pathway — a staged, evidence-based plan such as a menopause work-up-to-treatment pathway — is a set of steps with prerequisite dependencies; sequencing puts them in a safe order. In a new pure lib/care-pathway.ts, evaluateCarePathway(request) takes a pathway (a pathway reference, a patient reference, and the steps, each declaring the prerequisite step ids that must precede it) and DETERMINISTICALLY runs Kahn's algorithm (repeatedly emitting a ready step — in-degree 0 — with the smallest step id, so ties break deterministically), reporting the disposition — sequenced (the ordered steps, with each step's stage = longest-prerequisite-chain depth), cannot-sequence-cycle-detected (the steps in a circular dependency, where no valid order exists), or cannot-sequence-missing-prerequisite (the steps whose prerequisites reference ids absent from the pathway). It COMPLEMENTS, not duplicates, the other clinical agents: distinct from the Care Plan agent (which AUTHORS a plan's goals / interventions / cadence from a template), the Transitions of Care and Care Coordination Handoff agents (moving a patient between settings / teams), the Prior Authorization agent (assembling a PA package), and the Drug Interaction / Controlled Substance agents (medication safety) — this ORDERS the steps of a pathway so no step is scheduled before its prerequisites. The determination is a pure function of the pathway's steps (no randomness, no clock), so the same pathway always yields the same order. A determination — a sequenced pathway, a detected cycle, OR a missing prerequisite — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresClinicianReview:true, autoExecuted:false), which is how a legitimate determination is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Drug Interaction and Enrollment Reconciliation agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.pathway.steps-sourced (signal pathwayStepsSourced, violating value false) blocks a determination that references a step id — in its ordered sequence, stage map, reported cycle members, or missing-prerequisite holders — that is not one of the submitted pathway steps, because a fabricated / dangling step id would order or flag care that doesn't exist — backed by the pure guard pathwayStepsSourced (mirroring the Drug Interaction Agent's interaction-sourced and the Enrollment Reconciliation Agent's actions-sourced posture); policy.pathway.sequence-valid (signal pathwaySequenceValid, violating value false) blocks a determination whose sequence is inconsistent with its steps — when reported SEQUENCED, the ordered steps must be a complete permutation of the pathway's steps (none dropped or duplicated) and every step must appear AFTER all of its prerequisites (ordering a treatment step before its safety-screening prerequisite is the worst failure mode), and when reported un-sequenceable no order may be asserted; the guard re-derives the ordering constraints from the steps and verifies them (this is the load-bearing correctness gate, mirroring the Member Cost-Share Agent's math-consistent and the Enrollment Reconciliation Agent's reconciliation-complete) — backed by the guard pathwaySequenceValid; and policy.pathway.no-autonomous-execution (signal pathwayNoAutonomousExecution, violating value false) blocks a determination that autonomously executed a step (autoExecuted:true — ordering a lab, a screening, or a therapy is a clinical action that must be authorized) or did not require clinician review (requiresClinicianReview:false) — the agent SEQUENCES, and every determination is a RECOMMENDATION requiring a clinician to confirm and order — backed by the guard pathwayNoAutonomousExecution (mirroring the Drug Interaction Agent's no-autonomous-hold-or-override and the Lab Result Agent's no-autonomous-clinical-action posture; the harmful action is enforced-off). It IS PHI-bearing — the pathway references the patient — so it reuses, by extending appliesTo, the HIPAA-audit policy (phiAccessed:true throughout), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/care-pathway/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — pathway.receive-steps → pathway.check-prerequisites → pathway.topological-sort → pathway.log-audit — with phiAccessed:true, returning the CarePathwayDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Care Pathway panel (a menopause work-up pathway preset → sequenced into 5 stages, shown staged; a circular-dependency preset → cannot-sequence-cycle-detected; a missing-prerequisite preset → cannot-sequence-missing-prerequisite; plus fabricated-step / invalid-order / auto-executed governance-block presets), a seeded pathway.receive-steps→check-prerequisites→topological-sort→log-audit trace showing the sequenced menopause pathway (6 steps across 5 stages, requiresClinicianReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'seventy-five agents', with the Care Pathway agent on the clinical-decision tier alongside the Care Plan and the other clinical agents) all reflect it. Menopause-relevant: a menopause work-up pathway — baseline labs, then confirm-diagnosis + cardiovascular / breast-cancer risk screening in parallel, then a shared decision-making visit, then initiate MHT or non-hormonal therapy, then a 3-month follow-up — is exactly the kind of dependency-ordered pathway this sequences so the risk screening always precedes the treatment decision. Frontend tests green (3,213 tests — + care-pathway topological-sort / respects-prerequisites / cycle-detection / missing-prerequisite / determinism / tie-break-by-id / three-signal-true-and-false guards, the route's envelope / three governance blocks / sequenced + cycle + missing happy paths, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to seventy-five agents); the pathways + steps are clearly-labeled illustrative synthetics, NOT a certified clinical pathway engine — real pathway management uses evidence-based order sets, the patient's clinical context, scheduling / timing constraints, and the care team's judgment. Lint + build clean.
Agent Fabric: added the Eligibility & Enrollment (834) Reconciliation agent — deterministic keyed set-difference + field-level comparison of a group's employer roster against the carrier's roster, producing enroll / terminate / update / no-change actions, with every member accounted for exactly once, every action sourced (no fabricated discrepancy), and never an autonomous enrollment change (the 74th agent)
ShippedDetails
Added the seventy-fourth agent on the fabric — enrollment-reconciliation-agent, a DETERMINISTIC (no-Claude) claims / payer-operations service on the payer & plan operations plane, reusing the existing payer-operations tier as a SIBLING to the Claims Adjudication, Coordination of Benefits, Claims Overpayment & Recovery, Timely Filing, Subrogation, Member Cost-Share / EOB, Medical Loss Ratio (MLR) Rebate, and OIG Exclusion agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic from every prior agent: there is NO date math (unlike the Amendment, Right of Access, and Timely Filing agents), NO single-record classifier (unlike the Information Blocking agent), NO pairwise lookup (unlike the Drug Interaction agent), and — crucially — it is NOT the Member Cost-Share agent's SEQUENTIAL dollar waterfall, the OIG Exclusion agent's identity MATCHING, or the MLR Rebate agent's RATIO + apportionment: the heart of the service is a KEYED SET-DIFFERENCE + a FIELD-LEVEL COMPARISON. The X12 834 EDI transaction is how employers send enrollment to carriers; the two sides drift — a new hire the carrier hasn't loaded, a departed employee still on the carrier, a coverage-tier change that didn't propagate — and reconciliation finds the delta. In a new pure lib/enrollment-reconciliation.ts, evaluateEnrollmentReconciliation(request) takes a reconciliation request (a group reference, the source-of-truth roster — the employer / HR feed, the carrier's current roster, and optionally which fields to compare) and DETERMINISTICALLY keys both rosters by member id, walks the UNION, and classifies each member — in source only → enroll; in carrier only → terminate; in both with a differing compared field → update (listing the field deltas); in both and identical → no-change. It COMPLEMENTS, not duplicates, the other payer-operations agents: distinct from the Claims Adjudication agent (the allowed amount), the Member Cost-Share agent (splitting ONE claim into member vs. plan), the Coordination of Benefits agent (the order of coverages), the MLR Rebate agent (a plan-year rebate), and the OIG Exclusion agent (screening a party against the sanctions list) — this reconciles WHO is enrolled, the membership roster itself, between the employer and the carrier. The determination is a pure function of the two rosters (no randomness, no clock), so the same two rosters always yield the same actions. A reconciliation — any set of actions, including all-no-change — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresBenefitsAdminReview:true, autoApplied:false), which is how a legitimate reconciliation is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Member Cost-Share, MLR Rebate, and OIG Exclusion agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.enrollment.reconciliation-complete (signal reconciliationComplete, violating value false) blocks a determination that does not account for EVERY member EXACTLY once — the per-kind counts must sum to the number of actions, the total-members count must equal the number of actions, the counts must match the actual per-kind tallies, and no member may appear twice; a dropped member is the worst failure mode (a terminated employee who keeps coverage, or a new hire who never gets enrolled) — this is the load-bearing correctness gate (mirroring the Member Cost-Share Agent's math-consistent and the MLR Rebate Agent's allocation-consistent) — backed by the pure guard reconciliationComplete; policy.enrollment.actions-sourced (signal reconciliationActionsSourced, violating value false) blocks a determination carrying a fabricated discrepancy or a mis-shaped action — every UPDATE must carry at least one genuinely-differing field (each delta's source value actually differs from its carrier value), and every NO-CHANGE / ENROLL / TERMINATE must carry none; an 'update' whose fields don't actually differ, or a 'no-change' that hides a real difference, drives wrong enrollment writes — backed by the guard reconciliationActionsSourced (mirroring the OIG Exclusion Agent's match-not-overstated and the Drug Interaction Agent's interaction-sourced posture); and policy.enrollment.no-autonomous-change (signal reconciliationNoAutonomousChange, violating value false) blocks a determination that autonomously applied the enrollment changes (autoApplied:true — enrolling / terminating / updating a member is a coverage decision that must be authorized) or did not require benefits-admin review (requiresBenefitsAdminReview:false) — the agent RECONCILES, and every determination is a RECOMMENDATION requiring a benefits administrator to confirm and post — backed by the guard reconciliationNoAutonomousChange (mirroring the Member Cost-Share Agent's no-autonomous-member-charge and the MLR Rebate Agent's no-autonomous-disbursement posture; the harmful action is enforced-off). It IS PHI-bearing — the rosters reference members and their coverage — so it reuses, by extending appliesTo, the HIPAA-audit policy (phiAccessed:true throughout, unlike the NON-PHI MLR Rebate and OIG Exclusion agents), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/enrollment-reconciliation/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — enrollment.receive-rosters → enrollment.diff-rosters → enrollment.classify-actions → enrollment.log-audit — with phiAccessed:true, returning the EnrollmentReconciliationDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Enrollment Reconciliation panel (a drifted-rosters preset → one of each action, with the coverageTier delta shown; an agreeing-rosters preset → all no-change; a new-group empty-carrier preset → all enroll; plus dropped-member / fabricated-discrepancy / auto-applied governance-block presets), a seeded enrollment.receive-rosters→diff-rosters→classify-actions→log-audit trace showing the four-member drift (1 enroll / 1 terminate / 1 update / 1 no-change, requiresBenefitsAdminReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'seventy-four agents', with the Enrollment Reconciliation agent on the payer-operations tier alongside the Member Cost-Share, MLR Rebate, and the other payer agents) all reflect it. Menopause-relevant: a 45-64 woman whose employer changed her from employee-only to family coverage after a qualifying event is exactly the kind of tier-change this reconciliation catches when it didn't propagate to the carrier — so her claims adjudicate correctly. Frontend tests green (3,178 tests — + enrollment field-deltas / drift-classification / all-no-change / all-enroll / sort-and-determinism / custom-compared-fields / three-signal-true-and-false guards, the route's envelope / three governance blocks / drift + clean + new-group happy paths, the panel's presets / request-body / view-lift, and the registry + brief drift guards raised to seventy-four agents); the rosters + compared fields are clearly-labeled illustrative synthetics, NOT a certified 834 / enrollment system — real reconciliation uses the full X12 834 transaction set, effective-dating / retroactivity rules, dependent / COBRA / qualifying-event handling, and the carrier's eligibility system. Lint + build clean.
Agent Fabric: added the Medical Loss Ratio (MLR) Rebate Calculation agent — deterministic ACA MLR computation that, when a plan falls short of its market standard, apportions the rebate owed across subscribers penny-exactly, with the standard sourced to the market catalog, an MLR + apportionment that always add up, and never an autonomous disbursement (the 73rd agent)
ShippedDetails
Added the seventy-third agent on the fabric — mlr-rebate-agent, a DETERMINISTIC (no-Claude), NON-PHI claims / payer-operations service on the payer & plan operations plane, reusing the existing payer-operations tier as a SIBLING to the Claims Adjudication, Coordination of Benefits, Claims Overpayment & Recovery, Timely Filing, Subrogation, Member Cost-Share / EOB, and OIG Exclusion agents — it does NOT invent a new tier or plane. It is DELIBERATELY a DIFFERENT KIND of logic from the recent agents: there is NO date math (unlike the Amendment, Right of Access, and Timely Filing agents), NO single-record classifier (unlike the Information Blocking agent), NO pairwise lookup (unlike the Drug Interaction agent), and — crucially — it is NOT the Member Cost-Share agent's SEQUENTIAL dollar waterfall or the OIG Exclusion agent's identity MATCHING: the heart of the service is a RATIO-vs-THRESHOLD test + an EXACT PROPORTIONAL APPORTIONMENT (largest-remainder / Hamilton method). The ACA (45 CFR Part 158) requires insurers to spend a minimum share of premium on care + quality improvement (80% individual / small-group, 85% large-group) and to REBATE the shortfall to subscribers. In a new pure lib/mlr-rebate.ts, evaluateMlrRebate(request) takes a rebate request (a plan reference, the market, the plan-year earned premium / incurred claims / quality-improvement expense / taxes & fees, and the subscriber premium roster) and DETERMINISTICALLY computes the MLR = (incurred claims + quality improvement) / (earned premium − taxes & fees), decides whether it meets the market standard, computes the total rebate owed = max(0, standard − MLR) × earned premium, and apportions it across the subscribers penny-exactly via apportionLargestRemainder() — every share gets the floor of its exact proportional cents, then the leftover cents go one-at-a-time to the largest fractional remainders, so the allocated cents sum EXACTLY to the total (no penny lost or invented). It COMPLEMENTS, not duplicates, the other payer-operations agents: distinct from the Claims Adjudication agent (the allowed amount), the Member Cost-Share agent (splitting ONE claim's allowed amount into member vs. plan), the Coordination of Benefits agent (the order of coverages), the Overpayment & Recovery agent (clawing back an overpayment), and the Subrogation agent (third-party recovery) — this computes a PLAN-YEAR-level rebate owed to subscribers under the ACA MLR rule and apportions it fairly. The determination is a pure function of the request's own fields + the market standard (no randomness, no clock), so the same plan year always yields the same MLR + rebate + apportionment. A determination — a rebate owed OR the standard met (no rebate) — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresTreasuryReview:true, autoDisbursed:false), which is how a legitimate determination is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Member Cost-Share and OIG Exclusion agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.mlr.inputs-sourced (signal mlrInputsSourced, violating value false) blocks a determination whose applied standard is off-catalog or does not match its market — the applicable standard must resolve in the recorded MLR_STANDARDS catalog for the market, because a mis-stated standard wrongly triggers or wrongly avoids a rebate — backed by the pure guard mlrInputsSourced (mirroring the Member Cost-Share Agent's benefit-design-sourced and the Good Faith Estimate Agent's charge-master-sourced posture); policy.mlr.allocation-consistent (signal mlrAllocationConsistent, violating value false) blocks a determination whose MLR does not equal (claims + quality improvement) / (earned premium − taxes & fees), whose total rebate does not equal max(0, standard − MLR) × earned premium, or whose per-subscriber allocations do not sum EXACTLY (to the penny) to the total rebate (or where an allocation is negative) — a rebate that doesn't add up, or an apportionment that loses / invents pennies, is a compliance and accounting defect; the guard recomputes the ratio, the total, and the penny-exact sum (this is the load-bearing correctness gate, mirroring the Member Cost-Share Agent's math-consistent and the Risk Adjustment Agent's score-consistent) — backed by the guard mlrAllocationConsistent; and policy.mlr.no-autonomous-disbursement (signal mlrNoAutonomousDisbursement, violating value false) blocks a determination that autonomously disbursed the rebate (autoDisbursed:true — a movement of money to members that must be authorized) or did not require treasury review (requiresTreasuryReview:false) — the agent CALCULATES, and every determination is a RECOMMENDATION requiring a treasury / compliance reviewer to confirm and issue payment — backed by the guard mlrNoAutonomousDisbursement (mirroring the Member Cost-Share Agent's no-autonomous-member-charge and the OIG Exclusion Agent's no-autonomous-block-or-clear posture; the harmful action is enforced-off). It is deliberately NOT PHI-bearing — it works on AGGREGATE plan-year financials + a subscriber premium roster, no patient health information — so it is NOT on the HIPAA-audit policy (phiAccessed:false throughout, like the OIG Exclusion agent), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/mlr-rebate/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — mlr.receive-financials → mlr.compute-ratio → mlr.apportion-rebate → mlr.log-audit — with phiAccessed:false, returning the MlrRebateDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new MLR Rebate panel (an individual 77.89% < 80% preset → $21,100 rebate apportioned 8,440 / 7,385 / 5,275; a large-group 89.58% ≥ 85% preset → standard met, no rebate; a small-group $8,400 preset whose uneven premiums exercise the largest-remainder penny distribution; plus off-catalog-standard / inconsistent-apportionment / auto-disbursed governance-block presets), a seeded mlr.receive-financials→compute-ratio→apportion-rebate→log-audit trace showing the individual-market rebate ($21,100, requiresTreasuryReview:true, phiAccessed:false), the console subtitle, and the investor brief (now 'seventy-three agents', with the MLR Rebate agent on the payer-operations tier alongside the Member Cost-Share and the other payer agents) all reflect it. Menopause-relevant: a 45-64 woman in an individual-market plan is exactly a subscriber who receives an MLR rebate check when her insurer under-spends on care — and who benefits from the apportionment being exact and audit-defensible. Frontend tests green (3,142 tests — + mlr standards-catalog / largest-remainder-sums-exactly / leftover-cent-to-largest-remainder / individual-rebate / large-group-meets / small-group-uneven / determinism / three-signal-true-and-false guards, the route's envelope / three governance blocks / individual + large-group + small-group happy paths, the panel's request-body + view-lift, and the registry + brief drift guards raised to seventy-three agents); the market standards + simplified MLR formula are clearly-labeled illustrative synthetics (no NAIC MLR Annual Reporting Form, credibility adjustments, multi-year averaging, or permitted claim / premium adjustments), NOT a certified MLR filing system — real MLR reporting is governed by 45 CFR Part 158. Lint + build clean.
Agent Fabric: added the Drug–Drug Interaction (DDI) Safety Check agent — deterministic screening of a proposed medication against the patient's active list, with every interaction sourced to the knowledge base, an overall severity that can never be inflated or suppressed, and never an autonomous order hold or alert override (the 72nd agent)
ShippedDetails
Added the seventy-second agent on the fabric — drug-interaction-agent, a DETERMINISTIC (no-Claude) clinical-decision service on the patient / clinical plane, reusing the existing clinical-decision tier as a SIBLING to the Controlled Substance / PDMP Safety Check, Formulary & DUR Review, Medication Adherence, Prior Authorization, Immunization Forecasting, Lab Result, and Claude Care Router agents — it does NOT invent a new tier or plane, and it is a RETURN TO THE PATIENT / CLINICAL PLANE after three platform / data-substrate agents (Amendment, Information Blocking, and the Accounting-of-Disclosures substrate work). It is DELIBERATELY a DIFFERENT KIND of logic from the recent agents: there is NO date math (unlike the Amendment, Right of Access, and Timely Filing agents), NO dollar waterfall (unlike the Member Cost-Share agent), and NO single-record exception classifier (unlike the Information Blocking agent) — the heart of the service is a PAIRWISE KNOWLEDGE-BASE LOOKUP + a SEVERITY RANKING. In a new pure lib/drug-interaction.ts, evaluateDrugInteractions(request) takes a screen request (a patient reference, a proposed / new drug, and the patient's active medication list) and DETERMINISTICALLY pairs the proposed drug with each active medication, looks up every recorded interaction in an illustrative DDI_INTERACTIONS knowledge base (order-independent via a sorted-pair key), ranks the detected interactions by severity (contraindicated > major > moderate > minor via DDI_SEVERITY_RANK), reports the overall severity + each interaction's mechanism + management, and decides the disposition (no-interaction-detected / monitor / review-recommended / review-required / do-not-coadminister-needs-review). It COMPLEMENTS, not duplicates, the other clinical / medication agents: distinct from the Controlled Substance / PDMP agent (the TOTAL controlled-substance MME burden across prescribers), the Formulary & DUR Review agent (plan-level coverage / step therapy), the Medication Adherence agent (taking an already-prescribed drug), the Prior Authorization agent (assembling a PA package), and the Immunization agent (the vaccine schedule) — this screens whether a NEW drug INTERACTS with what the patient already takes. The determination is a pure function of the request's own fields (no randomness, no clock), so the same proposed drug + active list always yields the same interactions + overall severity + disposition. A finding — an interaction of any severity OR no interaction — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresClinicianReview:true, autoHeldOrder:false, autoOverrodeAlert:false), which is how a legitimate finding is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Controlled Substance and Lab Result agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.ddi.interaction-sourced (signal ddiInteractionSourced, violating value false) blocks a determination that reports an interaction that is off-catalog, or dresses a mismatched severity onto a recorded interaction — every flagged interaction must resolve in the recorded knowledge base with a matching pair + severity, because a fabricated interaction erodes clinician trust and drives alert fatigue — backed by the pure guard ddiInteractionSourced (mirroring the Controlled Substance Agent's guideline-sourced and the Immunization Agent's schedule-sourced posture); policy.ddi.severity-consistent (signal ddiSeverityConsistent, violating value false) blocks a determination whose overall severity does not equal the highest cataloged severity among the detected interactions — an INFLATED severity drives wrongful order cancellation and alert fatigue, and a SUPPRESSED severity hides a contraindication; the guard recomputes the maximum severity from the detected interactions' catalog records and verifies it matches (this is the load-bearing correctness gate, mirroring the Member Cost-Share Agent's math-consistent and the OIG Exclusion Agent's match-not-overstated) — backed by the guard ddiSeverityConsistent; and policy.ddi.no-autonomous-hold-or-override (signal ddiNoAutonomousHoldOrOverride, violating value false) blocks a determination that autonomously held / cancelled the order (autoHeldOrder:true — which could deny needed therapy), overrode the interaction alert (autoOverrodeAlert:true — which could push through a contraindicated combination), or did not require clinician review (requiresClinicianReview:false) — the agent SCREENS, and every finding is a RECOMMENDATION requiring a pharmacist / prescriber to act on or review — backed by the guard ddiNoAutonomousHoldOrOverride (mirroring the Controlled Substance Agent's no-autonomous-prescribing-decision and the Lab Result Agent's no-autonomous-clinical-action posture; the harmful action is enforced-off). It also reuses, by extending appliesTo, the HIPAA-audit policy (it is PHI-bearing — the screen references the patient's active medication list), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/drug-interaction/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — ddi.receive-order → ddi.match-interactions → ddi.rank-severity → ddi.log-audit — with phiAccessed:true, returning the DrugInteractionDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Drug Interaction panel (a paroxetine+tamoxifen preset → major interaction, review required; a nitroglycerin+sildenafil preset → contraindicated, do-not-coadminister; a rifampin+estradiol preset → moderate, review recommended; an acetaminophen preset → no interaction; plus off-catalog-interaction / inflated-severity / auto-held-order governance-block presets), a seeded ddi.receive-order→match-interactions→rank-severity→log-audit trace showing the paroxetine+tamoxifen major interaction (review-required, requiresClinicianReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'seventy-two agents', with the Drug Interaction agent on the clinical-decision tier alongside the Controlled Substance and the other clinical agents) all reflect it. Menopause-relevant: a 45-64 patient on tamoxifen who is newly prescribed paroxetine for hot flashes is exactly the major CYP2D6 interaction this screen catches before it reaches the pharmacy. Frontend tests green (3,104 tests — + drug-interaction catalog / normalize / order-independent-lookup / disposition-mapping / major / contraindicated / moderate / none / highest-severity / duplicate-med / determinism / three-signal-true-and-false guards, the route's envelope / three governance blocks / major + contraindicated + none happy paths, the panel's request-body + view-lift, and the registry + brief drift guards raised to seventy-two agents); the interaction knowledge base + severity assignments are clearly-labeled illustrative synthetics (no dose / route / timing context, no patient-specific factors, no normalized drug vocabularies), NOT a certified clinical decision support system — real interaction checking uses a maintained compendium, RxNorm, and the pharmacist's / prescriber's clinical judgment. Lint + build clean.
Agent Fabric: added the Information Blocking (21st Century Cures Act / 45 CFR Part 171) agent — deterministic adjudication of whether an actor's practice that interfered with EHI access is information blocking or fits a recorded exception, with exception-sourced claims, an exception that can never be overstated, and never an autonomous EHI withhold or release — the enforcement flip-side of the HIPAA patient-rights trilogy (the 71st agent)
ShippedDetails
Added the seventy-first agent on the fabric — information-blocking-agent, a DETERMINISTIC (no-Claude) control-plane / data-substrate compliance service on the platform plane, reusing the existing data-plane tier (planeForTier('data-plane') === 'platform') as a SIBLING to the Consent & Preferences Management, Master Patient Index, Break-the-Glass, Data Retention, De-Identification, Minimum Necessary, Audit Log Integrity, Accounting of Disclosures, Right of Access, and Amendment / Correction agents — it does NOT invent a new tier or plane, and it is the ENFORCEMENT FLIP-SIDE of the HIPAA PATIENT-RIGHTS TRILOGY: where the trilogy (Right of Access §164.524, Amendment §164.526, Accounting of Disclosures §164.528) gives a patient the RIGHT to get / fix / audit their record, the 21st Century Cures Act's information-blocking rule (45 CFR Part 171) prohibits a provider, health-IT developer, or HIE/HIN from INTERFERING with the access, exchange, or use of electronic health information (EHI) unless the practice satisfies ALL the conditions of a recorded exception. It COMPLEMENTS, not duplicates, the HIPAA privacy agents: they grant a patient's RIGHTS to their record; this enforces that an actor does not INTERFERE with EHI access. It is DELIBERATELY a DIFFERENT KIND of logic from the recent agents — there is NO date math (unlike the Amendment, Right of Access, and Timely Filing agents) and NO dollar waterfall (unlike the Member Cost-Share agent): the heart of the service is a CONDITIONS-SATISFACTION classifier. In a new pure lib/information-blocking.ts, evaluateInformationBlocking(request) takes a practice review (an actor reference + type — provider / health-IT developer / HIE-HIN, the EHI request type — access / exchange / use, a short practice description, whether the practice actually interfered with access, an optional claimed exception, and the set of exception CONDITIONS the actor asserts are satisfied) and DETERMINISTICALLY checks the claimed exception against an illustrative BLOCKING_EXCEPTIONS catalog of the eight 45 CFR Part 171 exceptions across two categories (not-fulfilling requests: preventing harm §171.201, privacy §171.202, security §171.203, infeasibility §171.204, health IT performance §171.205; procedures for fulfilling requests: content & manner §171.301, fees §171.302, licensing §171.303), each carrying an illustrative set of required conditions, then VERIFIES via the shared missingConditionsFor() helper that EVERY required condition of that exception is satisfied, and decides the disposition (not-information-blocking-no-interference when the practice did not interfere; not-information-blocking-exception-met when a cataloged exception's every condition is satisfied; potential-information-blocking-needs-review otherwise — a missing condition, an off-catalog exception, or interference with no exception claimed). The determination is a pure function of the request's own fields (no randomness, no clock), so the same practice review always yields the same exception analysis + disposition. A determination — exception-met, no-interference, OR potential-blocking-needs-review — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresComplianceReview:true, autoBlockedEhi:false, autoReleasedEhi:false), which is how a legitimate determination is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Right of Access and OIG Exclusion agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.information-blocking.exception-sourced (signal blockingExceptionSourced, violating value false) blocks a determination that claims an exception that is off-catalog — a practice escapes the Cures Act information-blocking rule only on a recorded 45 CFR Part 171 exception, and an ad-hoc / un-sourced exception is not a lawful basis to interfere with EHI — backed by the pure guard blockingExceptionSourced (mirroring the Right of Access Agent's ground-sourced and the Amendment Agent's ground-sourced posture); policy.information-blocking.determination-not-overstated (signal blockingDeterminationNotOverstated, violating value false) blocks a determination that reports an exception as SATISFIED (or under-reports its missing conditions) when a required condition of that exception is not met — each exception's conditions must ALL be satisfied, and an overstated 'exception met' is how unlawful interference with EHI is dressed up as a compliant practice; the guard recomputes the missing conditions from the claimed exception + the asserted conditions and verifies exceptionSatisfied / missingConditions match (this is the load-bearing correctness gate, mirroring the OIG Exclusion Agent's match-not-overstated and the Member Cost-Share Agent's math-consistent) — backed by the guard blockingDeterminationNotOverstated; and policy.information-blocking.no-autonomous-block-or-release (signal blockingNoAutonomousBlockOrRelease, violating value false) blocks a determination that autonomously withheld EHI (autoBlockedEhi:true — which could itself be information blocking, or delay urgent care), force-released EHI (autoReleasedEhi:true — which could breach privacy), or did not require compliance review (requiresComplianceReview:false) — the agent ADJUDICATES, and every determination is a RECOMMENDATION requiring a compliance officer to confirm and act — backed by the guard blockingNoAutonomousBlockOrRelease (mirroring the OIG Exclusion Agent's no-autonomous-block-or-clear and the Right of Access Agent's no-autonomous-denial-or-release posture; the harmful action is enforced-off). It also reuses, by extending appliesTo, the HIPAA-audit policy (it is EHI-bearing — the review references a request for the patient's electronic health information), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/information-blocking/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — blocking.receive-practice → blocking.assess-exception → blocking.check-conditions → blocking.log-audit — with phiAccessed:true, returning the InformationBlockingDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Information Blocking panel (a privacy-exception-fully-met preset → not information blocking; a request-fulfilled-normally preset → not information blocking, no interference; an infeasibility-missing-a-condition preset → potential information blocking, needs review; an interference-with-no-exception preset → potential information blocking, needs review; plus off-catalog-exception / overstated-exception / auto-blocked-EHI governance-block presets), a seeded blocking.receive-practice→assess-exception→check-conditions→log-audit trace showing a privacy-precondition hold with every condition satisfied (not-information-blocking-exception-met, requiresComplianceReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'seventy-one agents', with the Information Blocking agent on the platform data-plane tier alongside the Right of Access, Amendment, and the other substrate agents — the enforcement flip-side of the patient-rights trilogy) all reflect it. Frontend tests green (3,058 tests — + information-blocking exception-catalog / missing-conditions / exception-met / no-interference / missing-condition / no-exception / off-catalog / determinism / three-signal-true-and-false guards, the route's envelope / three governance blocks / exception-met + no-interference + missing-condition happy paths, the panel's request-body + view-lift, and the registry + brief drift guards raised to seventy-one agents); the exception catalog + condition sets are clearly-labeled illustrative synthetics, NOT certified information-blocking compliance counsel — real analysis is governed by the 21st Century Cures Act and 45 CFR Part 171 (the full text of the eight exceptions and every sub-condition), the ONC / ASTP rules, and OIG enforcement (§171 penalties / disincentives). Lint + build clean.
Agent Fabric: added the Amendment / Correction (HIPAA §164.526) agent — deterministic adjudication of a patient's right to FIX their record, with ground-sourced denials, a computed 60/90-day response deadline, and never an autonomous amendment or denial — completing the HIPAA patient-rights trilogy (the 70th agent)
ShippedDetails
Added the seventieth agent on the fabric — amendment-request-agent, a DETERMINISTIC (no-Claude) control-plane / data-substrate privacy service on the platform plane, reusing the existing data-plane tier (planeForTier('data-plane') === 'platform') as a SIBLING to the Consent & Preferences Management, Master Patient Index, Break-the-Glass, Data Retention, De-Identification, Minimum Necessary, Audit Log Integrity, Accounting of Disclosures, and Right of Access agents — it does NOT invent a new tier or plane, and it CAPSTONES the HIPAA PATIENT-RIGHTS TRILOGY: it is the third leg alongside the Right of Access agent (§164.524 — the right to GET a copy of your record) and the Accounting of Disclosures agent (§164.528 — the right to know WHO your PHI was disclosed to); this answers the §164.526 right to FIX your record. It COMPLEMENTS, not duplicates, the other platform / privacy agents: distinct from the Right of Access agent (§164.524 — GET a copy), the Accounting of Disclosures agent (§164.528 — WHO it was disclosed to), the Consent & Preferences Management agent (WHETHER a patient may be contacted / data used), the Minimum Necessary agent (HOW MUCH PHI a purpose may see), and the Data Retention agent (records disposition), this answers the patient's §164.526 RIGHT to request an AMENDMENT / CORRECTION of the record, and BY WHEN. It is a DETERMINISTIC, no-Claude agent: in a new pure lib/amendment-request.ts, evaluateAmendment(request) takes an amendment request (a patient reference, the record and request type, the request date, an as-of date, whether the PHI is in a designated record set, whether the covered entity created the PHI and whether the originator is available, whether the PHI is available for access under §164.524, whether the PHI is already accurate and complete, and whether the single 30-day extension was invoked) and DETERMINISTICALLY computes the §164.526 response deadline (request date + 60 days, or + 90 when the extension is invoked, via pure UTC date math — addDays / daysBetween, dates taken as data, NO Date.now()), derives which denial ground (if any) applies via the shared deriveDenialGround() helper in statutory precedence order against an illustrative AMENDMENT_DENIAL_GROUNDS catalog (the covered entity did not create the PHI and the originator is available; the PHI is not part of the designated record set; the PHI is not available for access under §164.524; or the PHI is already accurate and complete), and decides the disposition (recommend-accept / recommend-deny, the latter carrying the patient's statement-of-disagreement rights). The determination is a pure function of the request's own fields (no randomness, no clock), so the same request always yields the same deadline + ground + disposition. A determination — accept OR deny — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresHumanReview:true, autoAmended:false, autoDenied:false), which is how a legitimate determination is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Right of Access and Accounting of Disclosures agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.amendment.ground-sourced (signal amendmentGroundSourced, violating value false) blocks a determination that denies (or asserts a denial ground) that is off-catalog — a §164.526 denial is permitted only on a recorded statutory ground, and an ad-hoc / un-sourced ground is not a lawful basis to refuse a patient's amendment (it also rejects an accept that improperly asserts a denial ground) — backed by the pure guard amendmentGroundSourced (mirroring the Right of Access Agent's ground-sourced and the Accounting of Disclosures Agent's purpose-category-sourced posture); policy.amendment.deadline-computed (signal amendmentDeadlineComputed, violating value false) blocks a determination whose response deadline (or days-until) does not equal the request date + 60 days (+ 30 more when the single extension is invoked) — a guessed / mis-stated deadline is how an amendment request quietly runs past its §164.526 legal clock (this is the load-bearing correctness gate, mirroring the Right of Access Agent's deadline-computed and the Timely Filing Agent's deadline-computed — the determination echoes its own requestDate / asOfDate so the guard is self-contained and recomputes the deadline) — backed by the guard amendmentDeadlineComputed; and policy.amendment.no-autonomous-write-or-denial (signal amendmentNoAutonomousWrite, violating value false) blocks a determination that autonomously amended the record (autoAmended:true — a data write to the medical record that ripples to every downstream holder the PHI was shared with), denied the request (autoDenied:true — a legal act carrying the patient's statement-of-disagreement rights), or did not require human review (requiresHumanReview:false) — the agent ADJUDICATES, and every determination is a RECOMMENDATION requiring a records / privacy officer to act on or review — backed by the guard amendmentNoAutonomousWrite (mirroring the Right of Access Agent's no-autonomous-denial-or-release and the Minimum Necessary Agent's no-autonomous-over-disclosure posture; the harmful action is enforced-off). It also reuses, by extending appliesTo, the HIPAA-audit policy (it is PHI-bearing — the amendment decision references the patient's record), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/amendment-request/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — amendment.receive-request → amendment.assess-grounds → amendment.compute-deadline → amendment.log-audit — with phiAccessed:true, returning the AmendmentDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Amendment Request panel (a correctable-clinical-note preset → recommend accept, due in 60 days; an accurate-and-complete preset → recommend deny with statement-of-disagreement rights; a not-originator preset → recommend deny with a referral; a complex-request preset → recommend accept with the single 30-day extension invoked, deadline computed at 90 days; plus off-catalog-ground / wrong-deadline / auto-amended governance-block presets), a seeded amendment.receive-request→assess-grounds→compute-deadline→log-audit trace showing a correctable note (recommend-accept, due 2026-10-14 with 37 days remaining, requiresHumanReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'seventy agents', with the Amendment / Correction agent on the platform data-plane tier alongside the Right of Access and the other substrate agents — completing the patient-rights trilogy) all reflect it. Frontend tests green (3,013 tests — + amendment date-math / derive-ground precedence / accept / accurate-and-complete-deny / not-originator-deny / extension / determinism / three-signal-true-and-false guards, the route's envelope / three governance blocks / accept + accurate-deny + extension happy paths, the panel's request-body + view-lift, and the registry + brief drift guards raised to seventy agents); the denial-ground catalog + 60/90-day math are clearly-labeled illustrative synthetics, NOT a certified HIM system — real amendment is governed by HIPAA §164.526 (the full denial grounds, the written-denial + statement-of-disagreement + rebuttal process, and the duty to notify other holders of an accepted amendment) and the covered entity's Notice of Privacy Practices. Lint + build clean.
Agent Fabric: added the OIG Exclusion / Sanctions Screening agent — deterministic screening of a party against the OIG LEIE before payment, with a match-record-sourced catalog, a match strength that can never be overstated, and never an autonomous payment block or clear (the 69th agent)
ShippedDetails
Added the sixty-ninth agent on the fabric — exclusion-screening-agent, a DETERMINISTIC (no-Claude) claims / payer-operations service on the payer & plan operations plane, reusing the existing payer-operations tier as a SIBLING to the Claims Adjudication, Coordination of Benefits, Claims Overpayment & Recovery, Timely Filing, Subrogation, Member Cost-Share, Good Faith Estimate, and Balance Billing agents — it does NOT invent a new tier or plane. Federal law (Social Security Act §1128 / §1128A(a)(6); 42 CFR §1001) prohibits federal-program payment for items or services furnished, ordered, or prescribed by an OIG-EXCLUDED party, so plans and providers must SCREEN parties against the OIG List of Excluded Individuals / Entities (LEIE) before payment / contracting — and this agent does exactly that: in a new pure lib/exclusion-screening.ts, evaluateScreening(request) takes a screening request (a party reference and the party's identifiers — last name, first name, and optionally an NPI and a date of birth) and DETERMINISTICALLY matches the party against an illustrative EXCLUSION_RECORDS catalog, reporting a match STRENGTH grounded in which identifiers actually matched (via the shared supportableStrength() helper): a confirmed match requires an NPI match OR a full-name AND date-of-birth match; a full-name match with no DOB / NPI is probable; a last-name coincidence the first name / DOB doesn't corroborate is possible; otherwise no-match — with a recommended disposition (recommend-clear / recommend-review-possible / recommend-review-probable / recommend-block-pending-review). It COMPLEMENTS, not duplicates, the other agents: distinct from the Provider Credentialing agent (whether a provider is QUALIFIED — license, board certification, education), the Claims Adjudication Assistant (the allowed amount), and the FWA agent (suspected fraud on a claim), this screens a party's IDENTITY against the OIG exclusion list to prevent an improper PAYMENT to a sanctioned party. The match is a pure function of the party's own fields + the catalog (no randomness, no clock), so the same party always yields the same match strength. A determination — match OR no-match — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresComplianceReview:true, autoBlockedPayment:false, autoCleared:false), which is how a legitimate determination is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Member Cost-Share and Subrogation agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.exclusion.match-record-sourced (signal exclusionMatchSourced, violating value false) blocks a determination that reports a match (anything other than no-match) without citing a matchedExclusionId that resolves in the recorded LEIE catalog — a match asserted without a sourced exclusion record is not a lawful basis to hold a payment — backed by the pure guard exclusionMatchSourced (mirroring the Right of Access Agent's ground-sourced and the Subrogation Agent's basis-sourced posture); policy.exclusion.match-not-overstated (signal exclusionMatchNotOverstated, violating value false) blocks a determination whose reported match strength exceeds what the identifier signals support — a name coincidence dressed up as a confirmed exclusion — because overstating a match is how a legitimate provider's payment is wrongly held on a shared name (this is the load-bearing correctness gate, mirroring the Member Cost-Share Agent's math-consistent and the Subrogation Agent's recoverable-within-paid; the guard recomputes the supportable strength from the determination's own npiMatch / nameMatch / dobMatch signals) — backed by the guard exclusionMatchNotOverstated; and policy.exclusion.no-autonomous-block-or-clear (signal exclusionNoAutonomousBlockOrClear, violating value false) blocks a determination that autonomously blocked a payment (autoBlockedPayment:true), cleared a party (autoCleared:true), or did not require compliance review (requiresComplianceReview:false) — the screening is a RECOMMENDATION, and a compliance officer confirms the identity and acts, because a wrongful block denies a legitimate provider income and a wrongful clear risks paying a sanctioned party — backed by the guard exclusionNoAutonomousBlockOrClear (mirroring the Advance Beneficiary Notice Agent's no-autonomous-beneficiary-liability and the Member Cost-Share Agent's no-autonomous-member-charge posture; the harmful action is enforced-off). It is deliberately NOT PHI-bearing — it screens a provider / vendor's identity against a public exclusion list, not a patient's health information, so it is NOT on the HIPAA-audit policy (phiAccessed:false throughout), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/exclusion-screening/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — exclusion.receive-party → exclusion.match-leie → exclusion.recommend-disposition — with phiAccessed:false, returning the ScreeningDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Exclusion Screening panel (an exact-NPI-hit preset → confirmed match, recommend HOLD payment; a shared-last-name preset → possible coincidence honestly reported as NOT confirmed; a clean-party preset → no-match / recommend clear; plus unsourced-match / overstated-match / auto-block governance-block presets), a seeded exclusion.receive-party→match-leie→recommend-disposition trace showing a confirmed NPI hit (leie-1001, recommend-block-pending-review, requiresComplianceReview:true, phiAccessed:false), the console subtitle, and the investor brief (now 'sixty-nine agents', with the Exclusion Screening agent on the payer-operations tier alongside the Member Cost-Share and the other payer agents) all reflect it. Frontend tests green (2,964 tests — + exclusion-screening confirmed-NPI / possible-coincidence / no-match / probable / name+DOB-confirm / determinism / supportable-strength / three-signal-true-and-false guards, the route's envelope / three governance blocks / confirmed + coincidence + no-match happy paths, the panel's request-body + view-lift, and the registry + brief drift guards raised to sixty-nine agents); the exclusion catalog + match rules are clearly-labeled illustrative synthetics (no fuzzy / phonetic matching, no monthly LEIE reload, no SAM.gov / state Medicaid exclusion lists, no reinstatement handling), NOT a certified exclusion-screening system — real screening is governed by the OIG LEIE, the OIG Special Advisory Bulletin on the effect of exclusion, and the payer's screening policy. Lint + build clean.
Agent Fabric: added the Member Cost-Share / EOB Calculation agent — deterministic split of an adjudicated claim's allowed amount into member vs. plan via the deductible → coinsurance → out-of-pocket-max waterfall, with a benefit-design-sourced catalog, a bounded split (member + plan = allowed), and never an autonomous member charge (the 68th agent)
ShippedDetails
Added the sixty-eighth agent on the fabric — member-cost-share-agent, a DETERMINISTIC (no-Claude) claims / payer-operations service on the payer & plan operations plane, reusing the existing payer-operations tier as a SIBLING to the Claims Adjudication, Coordination of Benefits, Claims Overpayment & Recovery, Timely Filing, Subrogation, Good Faith Estimate, and Balance Billing agents — it does NOT invent a new tier or plane. Once a claim is adjudicated to an ALLOWED AMOUNT, the member's share must be split from the plan's, and this agent does exactly that: in a new pure lib/member-cost-share.ts, evaluateCostShare(request) takes a cost-share request (a claim reference, a member reference, the member's plan id, the adjudicated allowed amount, and the member's current accumulators — deductible-met and out-of-pocket-met to date) and DETERMINISTICALLY loads the plan benefit design (deductible, coinsurance rate, out-of-pocket maximum) from an illustrative BENEFIT_PLANS catalog and runs the classic deductible → coinsurance → out-of-pocket-max WATERFALL: the deductible is applied first (up to the remaining deductible), the post-deductible remainder is split by the coinsurance rate (the member's share), and the member's total is capped at the remaining OOP maximum — the plan pays the rest. It COMPLEMENTS, not duplicates, the other payer & plan operations agents: distinct from the Claims Adjudication Assistant (WHAT the allowed amount / medical necessity is — it produces the allowed amount this agent CONSUMES), the Coordination of Benefits agent (the ORDER of coverages), the Subrogation agent (recovery from a liable third party), the Good Faith Estimate agent (the pre-service uninsured / self-pay estimate), and the Balance Billing agent (surprise-bill protection at claim time), this splits the ALREADY-adjudicated allowed amount into member vs. plan responsibility using the benefit design + accumulators. The split is a pure function of the claim's own fields + the plan (no randomness, no clock), so the same claim always yields the same member / plan split. A determination — whatever the member's share works out to — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresAdjudicationReview:true, autoPostedCharge:false), which is how a legitimate determination is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Subrogation and Good Faith Estimate agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.costshare.benefit-design-sourced (signal costShareBenefitSourced, violating value false) blocks a determination whose plan is off-catalog (a missing or unrecognized plan id — the deductible / coinsurance rate / OOP maximum must come from the member's recorded benefit design, and an ad-hoc plan cannot be correctly cost-shared) — backed by the pure guard costShareBenefitSourced (mirroring the Good Faith Estimate Agent's charge-master-sourced and the Deal Desk Agent's pricing-catalog-sourced posture); policy.costshare.math-consistent (signal costShareMathConsistent, violating value false) blocks a determination whose split does not add up — member + plan ≠ allowed, the member share is negative or exceeds the allowed / remaining OOP maximum, the member total ≠ deductible + coinsurance − OOP-cap reduction, or the coinsurance ≠ the rate applied to the post-deductible remainder — because a split that doesn't add up is how a member is silently over-charged (this is the load-bearing correctness gate, mirroring the Subrogation Agent's recoverable-within-paid and the Good Faith Estimate Agent's math-consistent; the guard recomputes the split from the determination's own fields) — backed by the guard costShareMathConsistent; and policy.costshare.no-autonomous-member-charge (signal costShareNoAutonomousCharge, violating value false) blocks a determination that posted a charge / invoice / balance to the member (autoPostedCharge:true) or did not require adjudication review (requiresAdjudicationReview:false) — the EOB cost-share is an ESTIMATE / BREAKDOWN, and the claims system / a human finalizes it — backed by the guard costShareNoAutonomousCharge (mirroring the Balance Billing Agent's no-autonomous-balance-bill and the Advance Beneficiary Notice Agent's no-autonomous-beneficiary-liability posture; the harmful action is enforced-off). It also reuses, by extending appliesTo, the HIPAA-audit policy (it is PHI-bearing — the claim references the patient's care), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/member-cost-share/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — costshare.receive-claim → costshare.load-benefits → costshare.compute-cost-share → costshare.log-audit — with phiAccessed:true, returning the CostShareDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Member Cost-Share panel (a partway-through-deductible preset → a $500 deductible + $700 coinsurance = $1,200 member / $2,800 plan mixed split; a near-OOP-max preset → $1,000 coinsurance capped to $500, plan absorbs the rest; a no-deductible-met preset → the $800 allowed all lands on the member, plan pays $0; plus off-catalog-plan / bad-math / posted-charge governance-block presets), a seeded costshare.receive-claim→load-benefits→compute-cost-share→log-audit trace showing the mixed split ($4,000 allowed → $1,200 member / $2,800 plan on a Silver PPO, requiresAdjudicationReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'sixty-eight agents', with the Member Cost-Share agent on the payer-operations tier alongside the Subrogation and the other payer agents) all reflect it. Frontend tests green (2,919 tests — + member-cost-share waterfall / mixed-split / OOP-cap / full-deductible / off-catalog / accumulator / determinism / three-signal-true-and-false guards, the route's envelope / three governance blocks / mixed + OOP-cap + full-deductible happy paths, the panel's request-body + view-lift, and the registry + brief drift guards raised to sixty-eight agents); the plan catalog + deductible / coinsurance / OOP-max waterfall are clearly-labeled illustrative synthetics (no copays, tiering, family accumulators, or out-of-network penalties), NOT a certified claims / adjudication system — real cost-share is governed by the member's certificate of coverage / SBC, the payer's adjudication system, and applicable state / federal law. Lint + build clean.
Agent Fabric: added the Right of Access (HIPAA §164.524) agent — deterministic adjudication of a patient's right to GET a copy of their own PHI, with ground-sourced denials, a computed 30/60-day response deadline, and never an autonomous release or denial (the 67th agent)
ShippedDetails
Added the sixty-seventh agent on the fabric — right-of-access-agent, a DETERMINISTIC (no-Claude) control-plane / data-substrate privacy service on the platform plane, reusing the existing data-plane tier (planeForTier('data-plane') === 'platform') as a SIBLING to the Consent & Preferences Management, Master Patient Index, Break-the-Glass, Data Retention, De-Identification, Minimum Necessary, Audit Log Integrity, and Accounting of Disclosures agents — it does NOT invent a new tier or plane, and it CAPSTONES the PRIVACY SUITE by pairing the patient's §164.524 RIGHT to GET a copy of their record with the §164.528 accounting of who it was disclosed to. It COMPLEMENTS, not duplicates, the other platform / privacy agents: distinct from the Accounting of Disclosures agent (WHO the PHI was disclosed to, §164.528), the Consent & Preferences Management agent (WHETHER a patient may be contacted / data used), the Minimum Necessary agent (HOW MUCH PHI a purpose may see), the De-Identification agent (whether a dataset is still PHI), the Data Retention agent (records disposition), and the Audit Log Integrity agent (whether the audit TRAIL is tamper-evident), this answers the patient's §164.524 RIGHT to GET a copy of their own record, and BY WHEN. It is a DETERMINISTIC, no-Claude agent: in a new pure lib/right-of-access.ts, evaluateAccess(request) takes an access request (a patient reference, the request type, the request date, an as-of date, whether the requested PHI is in a designated record set, an optional cited denial-ground / exception, and whether the single 30-day extension was invoked) and DETERMINISTICALLY computes the §164.524 response deadline (request date + 30 days, or + 60 when the extension is invoked, via pure UTC date math — addDays / daysBetween, dates taken as data, NO Date.now()), classifies any cited exception against an illustrative ACCESS_EXCEPTIONS catalog (unreviewable grounds — psychotherapy notes, information compiled for a legal proceeding, a CLIA-exempt lab; reviewable grounds — access reasonably likely to endanger, a reference to another person), and decides the disposition (grant-in-full / deny-unreviewable / deny-reviewable-needs-review / not-accessible-outside-record-set). The determination is a pure function of the request's own fields (no randomness, no clock), so the same request always yields the same deadline + classification + disposition. A determination — grant OR deny — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresHumanReview:true, autoReleased:false), which is how a legitimate determination is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Accounting of Disclosures and Audit Log Integrity agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.access.ground-sourced (signal accessGroundSourced, violating value false) blocks a determination that denies (in part or full) on a cited ground that is off-catalog (a missing or unrecognized exception id — a §164.524 denial is permitted only on a recorded statutory ground, and an ad-hoc / un-sourced ground is not a lawful basis to withhold a patient's own record) — backed by the pure guard accessGroundSourced (mirroring the Accounting of Disclosures Agent's purpose-category-sourced and the Minimum Necessary Agent's purpose-of-use-sourced posture); policy.access.deadline-computed (signal accessDeadlineComputed, violating value false) blocks a determination whose response deadline (or days-until) does not equal the request date + 30 days (+ 30 more when the single extension is invoked) — a guessed / mis-stated deadline is how an access request quietly runs past its §164.524 legal clock (this is the load-bearing correctness gate, mirroring the Timely Filing Agent's deadline-computed and the Good Faith Estimate Agent's math-consistent — the guard recomputes the deadline from the determination's own fields) — backed by the guard accessDeadlineComputed; and policy.access.no-autonomous-denial-or-release (signal accessNoAutonomousDenialOrRelease, violating value false) blocks a determination that autonomously released the record (autoReleased:true) or did not require human review (requiresHumanReview:false) — the agent ADJUDICATES, it never releases the record (a privacy risk) or issues a denial (a legal act with appeal rights) on its own, and every determination is a RECOMMENDATION requiring a records / privacy officer to fulfill or review — backed by the guard accessNoAutonomousDenialOrRelease (mirroring the Accounting of Disclosures Agent's no-autonomous-suppression and the Minimum Necessary Agent's no-autonomous-over-disclosure posture; the harmful action is enforced-off). It also reuses, by extending appliesTo, the HIPAA-audit policy (it is PHI-bearing — the access decision references the patient's record), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/right-of-access/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — access.receive-request → access.assess-grounds → access.compute-deadline → access.log-audit — with phiAccessed:true, returning the AccessDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Right of Access panel (a routine-copy preset → grant in full, due in 30 days; a psychotherapy-notes preset → unreviewable denial; an endangerment preset → reviewable denial requiring a licensed reviewer; a complex-request preset → grant with the single 30-day extension invoked, deadline computed at 60 days; plus off-catalog-ground / wrong-deadline / auto-released governance-block presets), a seeded access.receive-request→assess-grounds→compute-deadline→log-audit trace showing a psychotherapy-notes request (deny-unreviewable, due 2026-09-24 with 17 days remaining, requiresHumanReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'sixty-seven agents', with the Right of Access agent on the platform data-plane tier alongside the Accounting of Disclosures and the other substrate agents) all reflect it. Frontend tests green (2,880 tests — + right-of-access date-math / grant / unreviewable / reviewable / extension / outside-record-set / off-catalog / determinism / three-signal-true-and-false guards, the route's envelope / three governance blocks / grant + unreviewable + reviewable + extension happy paths, the panel's request-body + view-lift, and the registry + brief drift guards raised to sixty-seven agents); the exception catalog + 30/60-day math are clearly-labeled illustrative synthetics, NOT a certified release-of-information system — real access is governed by HIPAA §164.524 (the full set of grounds for denial, the reviewable-denial review process, the fee limits, and the designated-record-set definition), the HITECH electronic-copy rules, and the covered entity's Notice of Privacy Practices. Lint + build clean.
Agent Fabric: added the Deal Desk / Quote Approval (CPQ) agent — deterministic validation of an enterprise quote's discounts against the deal-desk guardrail catalog, with pricing-catalog-sourced, discount-math-consistent, and never an autonomous out-of-guardrail approval (the 66th agent)
ShippedDetails
Added the sixty-sixth agent on the fabric — deal-desk-agent, a DETERMINISTIC (no-Claude) commercial-operations service on the strictly PHI-separated commercial plane, reusing the existing commercial-operations tier as a SIBLING to the Pipeline Management, Account Management, and Provider Contracting agents — it does NOT invent a new tier or plane, and it finally BALANCES the thinnest plane (commercial ops is now pipeline, account management, provider contracting, and deal desk). This is Pause's OWN go-to-market tooling (selling the platform to health systems / payers / employers), NOT a patient-facing agent: it runs on Sales Cloud commercial data only and never reads, joins, or derives patient PHI — so it is on the commercial no-PHI policy, NOT the HIPAA-audit policy. It COMPLEMENTS, not duplicates, the other commercial-operations agents: distinct from the Pipeline Management agent (the B2B opportunity pipeline / forecast roll-up), the Account Management agent (post-close renewals / expansion / health), and the Provider Contracting agent (the payer↔provider network CONTRACT, a different plane relationship), this validates a proposed SALES QUOTE's pricing and discounting against the deal-desk guardrails. It is a DETERMINISTIC, no-Claude agent: in a new pure lib/deal-desk.ts, evaluateQuote(request) takes a proposed quote (an account and a set of line items, each a product, its list price, a quantity, and a proposed discount %) and DETERMINISTICALLY prices each line, sums the list / net / discount totals, computes the effective blended discount, checks each line's discount against its product's max auto-approve guardrail from an illustrative DEAL_DESK_PRODUCTS catalog (a per-provider-org Platform Core at a 15% guardrail, Data 360 Activation at 20%, Premium Support at 10%, Implementation Services at 25%), and decides the disposition (auto-approve when every line is within guardrail / escalate-to-deal-desk when any line is over). The decision is a pure function of the quote's own line items + the catalog (no randomness, no clock — NO Date.now()), so the same quote always yields the same totals + guardrail result + disposition. A decision — auto-approve OR escalate — is a SAFE, honest OUTPUT: the task COMPLETES (an out-of-guardrail quote carries requiresDealDeskApproval:true), and a within-guardrail quote is genuinely auto-approvable (a standard-discount quote does not need a human — a low-risk commercial action, NOT a PHI / clinical decision), which is how a legitimate decision is distinguished from a governance block (the block fires only on a caller-asserted DECISION that violates a guard, mirroring the Provider Contracting and Account Management agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.dealdesk.pricing-catalog-sourced (signal dealDeskCatalogSourced, violating value false) blocks a decision that prices a line whose product is off-catalog (a missing or unrecognized product id — an ad-hoc product cannot be correctly priced or guardrailed against the recorded price book) — backed by the pure guard dealDeskCatalogSourced (mirroring the Provider Contracting Agent's contract-type-catalog-sourced and the Good Faith Estimate Agent's charge-master-sourced posture); policy.dealdesk.discount-math-consistent (signal dealDeskMathConsistent, violating value false) blocks a decision whose list / net / discount totals or effective discount do not equal the recomputed sums of its line items — a guessed / hidden total is how an out-of-guardrail quote is dressed up as compliant (this is the load-bearing correctness gate, mirroring the Good Faith Estimate Agent's math-consistent and the Subrogation Agent's recoverable-within-paid; the guard recomputes every line's list / net and the quote totals from the decision's own fields) — backed by the guard dealDeskMathConsistent; and policy.dealdesk.no-autonomous-out-of-guardrail-approval (signal dealDeskNoAutonomousApproval, violating value false) blocks a decision that auto-approves (autoApproved:true) — or does not require deal-desk approval for — a quote with any line whose discount exceeds its product's max auto-approve guardrail — an out-of-guardrail discount is a RECOMMENDATION that must escalate to a human deal-desk owner, never an autonomous approval — backed by the guard dealDeskNoAutonomousApproval (mirroring the Account Management Agent's human-owner-before-contract-change and the Provider Contracting Agent's no-autonomous-term-change posture; the harmful action is enforced-off). It reuses, by extending appliesTo, the commercial no-PHI policy (phiAccessed:false throughout — the commercial plane never touches patient PHI), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/deal-desk/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — dealdesk.receive-quote → dealdesk.validate-pricing → dealdesk.decide-approval → dealdesk.record-audit — with phiAccessed:false, returning the QuoteDecision as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Deal Desk panel (a standard-discounts preset → every line within guardrail, auto-approved; a 25%-on-Platform-Core preset → over the 15% guardrail, escalated to a human deal-desk owner; a services-at-the-25%-cap preset → a boundary case, still auto-approvable; plus off-catalog-product / totals-don't-add-up / out-of-guardrail-auto-approved governance-block presets), a seeded dealdesk.receive-quote→validate-pricing→decide-approval→record-audit trace showing an out-of-guardrail quote ($285,000 list / $216,000 net / 24.21% effective discount, escalate-to-deal-desk, requiresDealDeskApproval:true, phiAccessed:false), the console subtitle, and the investor brief (now 'sixty-six agents', with the Deal Desk agent on the commercial-operations tier alongside the Pipeline Management, Account Management, and Provider Contracting agents) all reflect it. Frontend tests green (2,838 tests — + deal-desk pricing / within-guardrail / out-of-guardrail-escalation / boundary / off-catalog / divide-by-zero / determinism / three-signal-true-and-false guards, the route's envelope / three governance blocks / auto-approve + escalate + boundary happy paths, the panel's request-body + view-lift, and the registry + brief drift guards raised to sixty-six agents); the product catalog + guardrail percentages are clearly-labeled illustrative synthetics, NOT a certified CPQ / pricing system — real quoting is governed by the company's CPQ (e.g. Salesforce Revenue Cloud), its approved price book, and its deal-desk / finance discount-approval matrix. Lint + build clean.
Agent Fabric: added the Subrogation / Third-Party Liability (TPL) agent — deterministic recovery of a plan's injury-claim payments from a liable third party's settlement, with basis-sourced, a bounded recoverable (≤ plan paid), and never an autonomous lien (the 65th agent)
ShippedDetails
Added the sixty-fifth agent on the fabric — subrogation-agent, a DETERMINISTIC (no-Claude) claims / payer-operations service on the payer & plan-operations plane, reusing the existing payer-operations tier as a SIBLING to the Claims Adjudication, Coordination of Benefits, Claims Overpayment & Recovery, Timely Filing, FWA Detection, and Utilization Review agents — it does NOT invent a new tier or plane, and it deepens the PAYER / REVENUE-CYCLE recovery side of the fabric. It COMPLEMENTS, not duplicates, the other payer-operations agents: distinct from the Claims Adjudication Assistant (per-claim edits / medical necessity), the Coordination of Benefits agent (the ORDER of coverages that both cover the member), the Claims Overpayment & Recovery agent (POST-payment clawback of the plan's OWN overpayment), the Timely Filing agent (was the claim filed in time), and the FWA agent (suspected fraud), this recovers the plan's injury-claim payments from a LIABLE THIRD PARTY's settlement. It is a DETERMINISTIC, no-Claude agent: in a new pure lib/subrogation.ts, evaluateSubrogation(request) takes a subrogation case (whether the claim is injury-related, the accident type, whether a liable third party is identified, what the plan PAID, the cited subrogation basis, the settlement amount if known, and whether the made-whole / common-fund doctrines apply) and DETERMINISTICALLY decides eligibility (injury-related AND a liable third party AND a real accident AND a recovery-allowing basis from an illustrative SUBROGATION_BASES catalog — an ERISA plan reimbursement clause, a state subrogation statute, a workers-comp lien, a contractual reimbursement provision), computes a BOUNDED recoverable amount (capped at the plan's paid amount, capped again at the settlement, barred by the made-whole doctrine, reduced by the common-fund attorney-fee share), and decides the disposition (no-subrogation-interest / notify-made-whole-bar / assert-lien-with-review). The determination is a pure function of the case's own fields + the cited basis (no randomness, no clock — NO Date.now()), so the same case always yields the same eligibility + recoverable + disposition. A determination — eligible or not — is a SAFE, honest OUTPUT: the task COMPLETES (an eligible case carries requiresHumanReview:true), which is how a legitimate determination is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Overpayment Recovery and Timely Filing agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.subrogation.basis-sourced (signal subrogationBasisSourced, violating value false) blocks a recovery decision that cites no recorded subrogation basis (a missing or off-catalog basis id — a subrogation interest exists only under a recorded legal basis, and an ad-hoc / un-sourced basis is not a real legal right) — backed by the pure guard subrogationBasisSourced (mirroring the Overpayment Recovery Agent's reason-catalog-sourced and the Timely Filing Agent's filing-limit-sourced posture); policy.subrogation.recoverable-within-paid (signal subrogationRecoverableWithinPaid, violating value false) blocks a determination whose recoverable is negative, exceeds the plan's paid amount, or exceeds the third-party settlement — a subrogation lien is REIMBURSEMENT, not profit: the plan may recover at most what it PAID and never more than the member's settlement (this is the load-bearing correctness gate, mirroring the Good Faith Estimate Agent's math-consistent and the Timely Filing Agent's deadline-computed — the guard recomputes the bound from the determination's own fields) — backed by the guard subrogationRecoverableWithinPaid; and policy.subrogation.no-autonomous-lien (signal subrogationNoAutonomousLien, violating value false) blocks a determination that autonomously asserts / perfects a lien (autoAssertedLien:true), or finds a subrogation interest (eligible:true) without requiring human review — a subrogation determination is a RECOMMENDATION requiring a subrogation specialist / plan counsel to review, and the agent never asserts or perfects a lien, reduces the member's settlement, or recovers funds — backed by the guard subrogationNoAutonomousLien (mirroring the Overpayment Recovery Agent's no-autonomous-clawback and the Balance Billing Agent's no-autonomous-balance-bill posture; the harmful action is enforced-off). It also reuses, by extending appliesTo, the HIPAA-audit policy (it is PHI-bearing — injury claims reference patient care), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/subrogation/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — subrogation.receive-case → subrogation.assess-eligibility → subrogation.compute-recoverable → subrogation.log-audit — with phiAccessed:true, returning the SubrogationDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Subrogation panel (an auto-accident preset → fully recoverable $42,000 under an ERISA plan clause, review-gated; a common-fund preset → $30,000 reduced 33% to $20,100; a made-whole preset → recovery BARRED at $0, notify and hold; a no-interest preset → non-injury claim, nothing to recover; plus off-catalog-basis / recoverable-exceeds-paid / auto-asserted-lien governance-block presets), a seeded subrogation.receive-case→assess-eligibility→compute-recoverable→log-audit trace showing a common-fund premises-liability case ($20,100 recoverable, assert-lien-with-review, requiresHumanReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'sixty-five agents', with the Subrogation agent on the payer-operations tier alongside the Coordination of Benefits, Overpayment & Recovery, Timely Filing, and Balance Billing agents) all reflect it. Frontend tests green (2,799 tests — + subrogation eligibility / common-fund / made-whole / settlement-cap / no-interest / off-catalog / determinism / three-signal-true-and-false guards, the route's envelope / three governance blocks / fully-recoverable + common-fund + made-whole + no-interest happy paths, the panel's request-body + view-lift, and the registry + brief drift guards raised to sixty-five agents); the subrogation bases, made-whole / common-fund reductions, and dollar figures are clearly-labeled illustrative synthetics, NOT a certified subrogation engine — real subrogation is governed by the plan document (for a self-funded ERISA plan, 29 U.S.C. §1132(a)(3) and cases such as US Airways v. McCutchen and Montanile), state subrogation / made-whole / common-fund law, and state workers-compensation statutes. Lint + build clean.
Agent Fabric: added the Accounting of Disclosures (HIPAA §164.528) agent — deterministic accounting of who a patient's PHI was disclosed to, with purpose-category-sourced, every-accountable-disclosure-complete, and never an autonomous suppression (the 64th agent)
ShippedDetails
Added the sixty-fourth agent on the fabric — accounting-of-disclosures-agent, a DETERMINISTIC (no-Claude) control-plane / data-substrate privacy service on the platform plane, reusing the existing data-plane tier (planeForTier('data-plane') === 'platform') as a SIBLING to the Consent & Preferences Management, Master Patient Index, Break-the-Glass, Data Retention, De-Identification, Minimum Necessary, and Audit Log Integrity agents — it does NOT invent a new tier or plane, and it completes the PRIVACY SUITE with the patient's §164.528 RIGHT to know WHO their PHI was disclosed to. It COMPLEMENTS, not duplicates, the other platform / privacy agents: distinct from the Consent & Preferences Management agent (WHETHER a patient may be contacted / data used), the Minimum Necessary agent (HOW MUCH PHI a purpose may see), the De-Identification & Safe Harbor agent (whether a dataset is still PHI), the Data Retention agent (records disposition), and the Audit Log Integrity agent (whether the audit TRAIL is tamper-evident), this answers WHO the patient's PHI was disclosed to, and for what non-TPO purpose, over the prior years. It is a DETERMINISTIC, no-Claude agent: in a new pure lib/accounting-of-disclosures.ts, evaluateAccounting(request) takes an accounting request (a patient reference, an as-of date, a lookback window in years, and the patient's disclosure log — each disclosure a date, a recipient, and the cited purpose-of-disclosure) and DETERMINISTICALLY computes the lookback window (as-of date − lookback years, via pure UTC date math — subtractYears, dates taken as data, NO Date.now()), classifies each disclosure against an illustrative DISCLOSURE_PURPOSES catalog (treatment / payment / operations and patient-authorized disclosures are EXCLUDED from the accounting; non-TPO disclosures — public-health mandates, law enforcement, judicial orders, research without authorization — ARE accountable) as in-accounting / excluded-TPO / excluded-authorized / out-of-window, and assembles the accounting of every accountable, in-window disclosure. The classification is a pure function of the request's own fields (no randomness, no clock), so the same log always yields the same classification + accounting + counts. A determination — however many accountable disclosures it lists — is a SAFE, honest OUTPUT: the task COMPLETES (it carries requiresPrivacyOfficerReview:true), which is how a legitimate determination is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Audit Log Integrity and Minimum Necessary agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.accounting.purpose-category-sourced (signal accountingPurposeSourced, violating value false) blocks a determination that classifies a disclosure whose purpose-of-disclosure is off-catalog (a missing or unrecognized purpose id — an ad-hoc purpose cannot be correctly decided as accountable or excluded under §164.528) — backed by the pure guard accountingPurposeSourced (mirroring the Minimum Necessary Agent's purpose-of-use-sourced and the Data Retention Agent's schedule-sourced posture); policy.accounting.accountable-disclosures-complete (signal accountingDisclosuresComplete, violating value false) blocks a determination that omits an accountable, in-window disclosure from the accounting (a non-TPO, non-authorized disclosure within the lookback window classified as anything other than in-accounting) — dropping an accountable disclosure understates the accounting and defeats the patient's §164.528 right (this is the load-bearing completeness gate, mirroring the Good Faith Estimate Agent's expected-items-complete and the Audit Log Integrity Agent's sequence-complete; the guard recomputes, from the determination's own classified list, which disclosures should be accounted and verifies none was dropped) — backed by the guard accountingComplete; and policy.accounting.no-autonomous-suppression (signal accountingNoAutonomousSuppression, violating value false) blocks a determination that claims it suppressed / redacted / deleted a logged disclosure (autonomousSuppression:true), or that does not require privacy-officer review — the agent CLASSIFIES and ASSEMBLES, it never deletes or suppresses a logged disclosure (that would falsify the accounting and destroy evidence), and the accounting is a RECOMMENDATION requiring privacy-officer review — backed by the guard accountingNoAutonomousSuppression (mirroring the Audit Log Integrity Agent's no-autonomous-redaction and the Minimum Necessary Agent's no-autonomous-over-disclosure posture; the harmful action is enforced-off). It also reuses, by extending appliesTo, the HIPAA-audit policy (it is PHI-bearing — disclosures reference patient care), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/accounting-of-disclosures/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — accounting.receive-log → accounting.classify → accounting.assemble → accounting.log-audit — with phiAccessed:true, returning the AccountingDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Accounting of Disclosures panel (a mixed-log preset → 2 accountable / 2 excluded-TPO / 1 out-of-window, privacy-officer review; a judicial+research preset → both accountable, an authorized disclosure excluded; a TPO-only preset → an empty accounting, still review-gated; plus off-catalog-purpose / dropped-accountable-disclosure / auto-suppressed governance-block presets), a seeded accounting.receive-log→classify→assemble→log-audit trace showing a mixed log (2 accountable, 6-year window from 2020-09-01, phiAccessed:true), the console subtitle, and the investor brief (now 'sixty-four agents', with the Accounting of Disclosures agent on the platform data-plane tier alongside the other substrate agents) all reflect it. Frontend tests green (2,768 tests — + accounting date-math / mixed-log / judicial+research / TPO-only / off-catalog / determinism / three-signal-true-and-false guards, the route's envelope / three governance blocks / mixed + judicial + TPO-only happy paths, the panel's request-body + view-lift, and the registry + brief drift guards raised to sixty-four agents); the purpose catalog + accountability rules are clearly-labeled illustrative synthetics, NOT a certified accounting-of-disclosures system — real accountings are governed by HIPAA §164.528 (the full exclusion set, the six-year window, and the electronic-health-record disclosure rules) and the covered entity's Notice of Privacy Practices. Lint + build clean.
Agent Fabric: added the Advance Beneficiary Notice (Medicare ABN) agent — deterministic Medicare coverage / pre-service-ABN decisioning with coverage-rule-sourced, ABN-required-when-non-covered, and never an autonomous patient bill (the 63rd agent)
ShippedDetails
Added the sixty-third agent on the fabric — advance-beneficiary-notice-agent, a DETERMINISTIC (no-Claude) patient-access / benefits-verification service on the patient & clinical plane, reusing the existing benefits-verification tier as a SIBLING to the Benefits & Coverage Verification (EBV), Patient Financial Assistance & Charity Care, and Good Faith Estimate agents — it does NOT invent a new tier or plane, and it deepens the PATIENT-ACCESS / price-transparency side of the fabric with the Medicare-specific ABN instrument. It COMPLEMENTS, not duplicates, its patient-access / financial siblings: distinct from the Good Faith Estimate agent (the No Surprises Act SELF-PAY / uninsured pre-service estimate), the Balance Billing agent (the No Surprises Act CLAIM-time surprise-bill prohibition), the EBV agent (plan eligibility), and the Financial Assistance agent (501(r) charity care), this decides one narrow Medicare question — is a signed pre-service ABN (Form CMS-R-131) required before a service Medicare is likely to DENY as not-reasonable-and-necessary (or statutorily excluded), and may the beneficiary be billed for it. It is a DETERMINISTIC, no-Claude agent: in a new pure lib/advance-beneficiary-notice.ts, evaluateAbn(request) takes a proposed service (the cited Medicare coverage rule, whether the service meets its coverage criteria or exceeds a frequency limit, and whether an ABN was issued and signed BEFORE the service) and DETERMINISTICALLY assesses coverage against an illustrative MEDICARE_COVERAGE_RULES catalog (a reasonable-necessary vitamin-D lab, a frequency-limited DEXA bone-density scan, a statutorily-excluded cosmetic procedure) as likely-covered / likely-non-covered / statutorily-excluded, decides whether a signed pre-service ABN is required, computes whether a valid pre-service ABN is on file (issued AND signed before the service), decides whether the beneficiary may be billed, assigns the CMS liability modifier (none / GA waiver-on-file / GZ expected-denial-no-ABN / GY statutorily-excluded), and decides the disposition (proceed-covered / issue-abn-before-service / bill-beneficiary-with-abn / notify-statutory-exclusion). The determination is a pure function of the request's own fields + the cited rule (no randomness, no clock — NO Date.now()), so the same service always yields the same coverage assessment + ABN requirement + modifier + disposition. A determination — covered, non-covered, or excluded — is a SAFE, honest OUTPUT: the task COMPLETES (a non-covered / excluded determination carries requiresHumanReview:true), which is how a legitimate determination is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Good Faith Estimate and Timely Filing agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.abn.coverage-rule-sourced (signal abnCoverageRuleSourced, violating value false) blocks a coverage / ABN decision that cites no recorded Medicare coverage rule (a missing or off-catalog rule id — an ad-hoc / un-sourced coverage decision is not a real determination) — backed by the pure guard abnCoverageRuleSourced (mirroring the Good Faith Estimate Agent's charge-master-sourced and the Timely Filing Agent's filing-limit-sourced posture); policy.abn.abn-required-when-noncovered (signal abnRequiredWhenNoncovered, violating value false) blocks a determination that assesses a service as likely NON-covered but marks it as needing no ABN (abnRequired:false) — a likely-denied Medicare service requires a signed ABN issued BEFORE the service, and understating this is how a surprise denial lands on the beneficiary (this is the load-bearing completeness gate, mirroring the Good Faith Estimate Agent's expected-items-complete) — backed by the guard abnRequiredWhenNoncovered; and policy.abn.no-autonomous-beneficiary-liability (signal abnNoAutonomousBeneficiaryLiability, violating value false) blocks a determination that assigns patient liability autonomously (autoAssignedLiability:true), bills the beneficiary for a likely-non-covered service WITHOUT a valid pre-service ABN, or assigns liability on a non-covered / excluded service without requiring human review — the beneficiary may be billed for a non-covered service ONLY with a valid ABN (the GA modifier), otherwise the PROVIDER is liable (the GZ modifier), and every liability decision is a RECOMMENDATION requiring human review — backed by the guard abnNoAutonomousBeneficiaryLiability (mirroring the Balance Billing Agent's no-autonomous-balance-bill and the Timely Filing Agent's no-autonomous-write-off posture; the harmful action is enforced-off). It also reuses, by extending appliesTo, the HIPAA-audit policy (it is PHI-bearing — services reference patient care), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/advance-beneficiary-notice/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — abn.receive-request → abn.assess-coverage → abn.decide-liability → abn.log-audit — with phiAccessed:true, returning the AbnDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Advance Beneficiary Notice panel (a meets-criteria preset → likely covered, no ABN required, proceed; a fails-criteria-no-ABN preset → likely non-covered, issue an ABN before the service, provider liable / GZ, beneficiary not billed, human review; a fails-criteria-with-valid-ABN preset → likely non-covered, beneficiary billable / GA, human review; a statutorily-excluded preset → GY, voluntary ABN, human review; plus un-sourced-rule / non-covered-no-ABN-required / billed-without-valid-ABN governance-block presets), a seeded abn.receive-request→assess-coverage→decide-liability→log-audit trace showing a likely-non-covered vitamin-D screen (abnRequired:true, GZ, issue-abn-before-service, requiresHumanReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'sixty-three agents', with the Advance Beneficiary Notice agent on the benefits-verification tier alongside the EBV, Financial Assistance, and Good Faith Estimate agents) all reflect it. Frontend tests green (2,738 tests — + ABN coverage-assessment / GZ / GA / GY / after-service-ABN / within-frequency-limit / off-catalog / determinism / three-signal-true-and-false guards, the route's envelope / three governance blocks / covered + non-covered + valid-ABN + excluded happy paths, the panel's request-body + view-lift, and the registry + brief drift guards raised to sixty-three agents); the coverage rules, categories, and modifier logic are clearly-labeled illustrative synthetics, NOT a certified Medicare coverage engine — real ABN decisions are governed by the Medicare National / Local Coverage Determinations (NCD/LCD), the Social Security Act §1862(a), the CMS Medicare Claims Processing Manual (Ch. 30), and Form CMS-R-131. Lint + build clean.
Agent Fabric: added the Controlled Substance / PDMP Safety Check agent — deterministic opioid MME screening with guideline-sourced, a computed (not guessed) MME total, and never an autonomous prescribing decision (the 62nd agent)
ShippedDetails
Added the sixty-second agent on the fabric — controlled-substance-agent, a DETERMINISTIC (no-Claude) clinical-decision service on the patient & clinical plane, reusing the existing clinical-decision tier (planeForTier('clinical-decision') === 'patient-care') as a SIBLING to the Care Router, Care Plan, Prior Authorization, Lab Result, and Immunization agents — it does NOT invent a new tier or plane, and it deliberately broadens the CLINICAL / medication-safety side of the fabric. It COMPLEMENTS, not duplicates, the other clinical / medication agents: distinct from the Formulary & DUR Review agent (plan-level coverage, step therapy, and drug-utilization-review alerts), the Medication Adherence agent (whether the patient is taking an already-prescribed drug), the Prior Authorization agent (assembling a payer PA package), and the Immunization Forecasting agent (vaccine schedule), this screens the TOTAL controlled-substance burden across ALL prescribers per the PDMP. It is a DETERMINISTIC, no-Claude agent: in a new pure lib/controlled-substance.ts, evaluateControlledSubstance(request) takes a proposed controlled-substance prescription (a drug, its class, its dose in MME/day, days supply, prescriber, pharmacy) and the patient's active PDMP (Prescription Drug Monitoring Program) history, and DETERMINISTICALLY sums the total opioid MME/day (morphine milligram equivalents; the proposed opioid contribution + the concurrent active opioids), flags a concurrent opioid+benzodiazepine combination (a respiratory-depression risk) and multi-prescriber / multi-pharmacy patterns, compares the total against the cited guideline's caution (50 MME/day) and high-risk (90 MME/day) thresholds, and classifies the risk (low / elevated / high). The finding is a pure function of the request's data + the cited guideline (no randomness, no clock — NO Date.now()), so the same request always yields the same total + risk + disposition. A determination — low or high risk — is a SAFE, honest OUTPUT: the task COMPLETES (an elevated / high-risk finding carries requiresPrescriberReview:true), which is how a legitimate determination is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Immunization and Lab Result agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.controlledsubstance.guideline-sourced (signal controlledSubstanceGuidelineSourced, violating value false) blocks a risk finding that cites no recorded guideline (a missing or off-catalog guideline id — an ad-hoc / un-sourced MME threshold is not a real clinical standard) — backed by the pure guard controlledSubstanceGuidelineSourced (mirroring the Immunization Agent's schedule-sourced and the Lab Result Agent's reference-range-sourced posture); policy.controlledsubstance.mme-computed (signal controlledSubstanceMmeComputed, violating value false) blocks a determination whose stated total MME/day does not equal the proposed opioid contribution + the concurrent opioid MME/day — a guessed / hidden dose is how an over-threshold prescription is wrongly called safe (this is the load-bearing correctness gate, mirroring the Timely Filing Agent's deadline-computed and the Good Faith Estimate Agent's math-consistent — the guard recomputes the sum from the determination's own fields) — backed by the guard controlledSubstanceMmeComputed; and policy.controlledsubstance.no-autonomous-prescribing-decision (signal controlledSubstanceNoAutonomousDecision, violating value false) blocks a determination that auto-decides (autoDecision:true), or that reports an elevated / high-risk finding without requiring prescriber review — a controlled-substance risk finding is a RECOMMENDATION requiring prescriber review, and the agent never autonomously approves, denies, dispenses, or writes the prescription — backed by the guard controlledSubstanceNoAutonomousDecision (mirroring the Immunization Agent's no-autonomous-administration and the Lab Result Agent's no-autonomous-clinical-action posture; the harmful action is enforced-off). It also reuses, by extending appliesTo, the HIPAA-audit policy (it is PHI-bearing — it screens a patient's controlled-substance history), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/controlled-substance/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — controlledsubstance.receive-request → controlledsubstance.compute-mme → controlledsubstance.classify → controlledsubstance.log-audit — with phiAccessed:true, returning the ControlledSubstanceDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Controlled Substance panel (a modest-opioid-no-history preset → low risk / proceed, no review; a stacked-opioids preset → total 100 MME/day over the 90 high-risk threshold → high risk / prescriber review; an opioid+benzo preset → high risk from the respiratory-depression combination; plus un-sourced-guideline / guessed-MME-total / auto-approved-high-risk governance-block presets), a seeded controlledsubstance.receive-request→compute-mme→classify→log-audit trace showing a stacked-opioid screen (100 MME/day, high risk, requiresPrescriberReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'sixty-two agents', with the Controlled Substance agent on the clinical-decision tier alongside the Care Router, Care Plan, Prior Authorization, Lab Result, and Immunization agents) all reflect it. Frontend tests green (2,707 tests — + controlled-substance MME-sum / stacked-opioid / opioid-benzo / non-opioid / off-catalog / determinism / three-signal-true-and-false guards, the route's envelope / three governance blocks / allow + high-risk + benzo happy paths, the panel's request-body + view-lift, and the registry + brief drift guards raised to sixty-two agents); the MME thresholds, drug classes, and MME/day figures are clearly-labeled illustrative synthetics, NOT a certified PDMP or clinical decision support — real monitoring uses the state PDMP, the CDC MME conversion factors, the CDC 2022 Clinical Practice Guideline for Prescribing Opioids, and the prescriber's clinical judgment. Lint + build clean.
Agent Fabric: added the Timely Filing Compliance agent — deterministic claim filing-deadline compliance with filing-limit-sourced, a computed (not guessed) deadline, and never an autonomous write-off (the 61st agent)
ShippedDetails
Added the sixty-first agent on the fabric — timely-filing-agent, a DETERMINISTIC (no-Claude) claims / payer-operations service on the payer & plan-operations plane, reusing the existing payer-operations tier as a SIBLING to the Claims Adjudication, Coordination of Benefits, Claims Overpayment & Recovery, FWA Detection, and Utilization Review agents — it does NOT invent a new tier or plane, and it deliberately broadens the PAYER / REVENUE-CYCLE side of the fabric. It COMPLEMENTS, not duplicates, the other payer-operations agents: distinct from the Claims Adjudication Assistant (per-claim edits / medical-necessity adjudication), the Coordination of Benefits agent (payer ORDER across coverages), the Claims Overpayment & Recovery agent (POST-payment clawback of a legitimate overpayment), the FWA Detection agent (suspected fraud patterns), and the Utilization Review agent (medical necessity), this decides one narrow, purely temporal question — was the claim FILED IN TIME. It is a DETERMINISTIC, no-Claude agent: in a new pure lib/timely-filing.ts, evaluateTimelyFiling(request) takes a claim (a date of service, a submission date, and the cited payer filing-limit rule, plus an optional claimed exception) and DETERMINISTICALLY computes the filing DEADLINE (date of service + the rule's limit in days, via pure UTC date math — addDays / daysBetween, dates taken as data, NO Date.now()), compares the submission date to it, computes how many days late an untimely claim is, honors a recognized filing-limit EXCEPTION when one is claimed (resolved against the rule's allowed exceptions — COB-primary-delay, retroactive eligibility, proof-of-timely-filing, provider-of-record error, administrative error), and decides the disposition (accept / appeal-with-exception / write-off-review). The decision is a pure function of the claim's dates + the cited rule (no randomness, no clock), so the same claim always yields the same deadline + timely flag + days-late + disposition. A determination — timely or untimely — is a SAFE, honest OUTPUT: the task COMPLETES (an untimely claim carries requiresHumanReview:true), which is how a legitimate determination is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Overpayment Recovery and Balance Billing agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.timelyfiling.filing-limit-sourced (signal timelyFilingRuleSourced, violating value false) blocks a timeliness decision that cites no recorded payer filing-limit rule (a missing or off-catalog rule id — an ad-hoc / un-sourced limit is not a real deadline) — backed by the pure guard timelyFilingRuleSourced (mirroring the Overpayment Recovery Agent's reason-catalog-sourced and the Data Retention Agent's schedule-sourced posture); policy.timelyfiling.deadline-computed (signal timelyFilingDeadlineComputed, violating value false) blocks a determination whose stated deadline does not equal the recomputed date of service + the rule's limit days — a guessed / hidden deadline is how a claim is wrongly called timely or untimely (this is the load-bearing correctness gate, mirroring the Good Faith Estimate Agent's math-consistent — the guard recomputes the deadline from the determination's own serviceDate + limitDays and compares) — backed by the guard timelyFilingDeadlineComputed; and policy.timelyfiling.no-autonomous-write-off (signal timelyFilingNoAutonomousWriteOff, violating value false) blocks a determination that marks the claim written-off, or that reports an untimely claim without requiring human review — an untimely claim is a RECOMMENDATION (file an appeal with a recognized exception, or route to a write-off decision) requiring human review, and the agent never autonomously writes off the balance or bills the patient — backed by the guard timelyFilingNoAutonomousWriteOff (mirroring the Overpayment Recovery Agent's no-autonomous-clawback and the Balance Billing Agent's no-autonomous-balance-bill posture; the harmful action is enforced-off). It also reuses, by extending appliesTo, the HIPAA-audit policy (it is PHI-bearing — claims reference patient care), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/timely-filing/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — timelyfiling.receive-claim → timelyfiling.compute-deadline → timelyfiling.decide → timelyfiling.log-audit — with phiAccessed:true, returning the TimelyFilingDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Timely Filing panel (a filed-within-90-days preset → timely / accept, no review; a late-but-exception preset → untimely with a recognized COB-primary-delay exception → appeal-with-exception, human review; a late-no-exception preset → untimely → write-off-review, human review, never auto-written-off; plus un-sourced-rule / guessed-deadline / auto-write-off governance-block presets), a seeded timelyfiling.receive-claim→compute-deadline→decide→log-audit trace showing a late-with-exception commercial claim (52 days late past a 2026-04-10 deadline, appeal-with-exception, requiresHumanReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'sixty-one agents', with the Timely Filing agent on the payer-operations tier alongside the Coordination of Benefits, Overpayment & Recovery, and Balance Billing agents) all reflect it. Frontend tests green (2,678 tests — + timely-filing date-math / accept / exception-appeal / write-off-review / off-catalog / determinism / three-signal-true-and-false guards, the route's envelope / three governance blocks / allow + exception-appeal happy paths, the panel's request-body + view-lift, and the registry + brief drift guards raised to sixty-one agents); the filing-limit rules, day windows, and exception catalog are clearly-labeled illustrative synthetics, NOT a certified timely-filing engine — real limits are governed by each payer's provider contract, Medicare (generally 12 months / 42 CFR 424.44), state Medicaid rules, and state prompt-pay law. Lint + build clean.
Agent Fabric: added the Audit Log Integrity (Tamper-Evidence) agent — deterministic hash-chain + sequence verification with hash-chain-verified, sequence-complete, and never an autonomous redaction (the 60th agent)
ShippedDetails
Added the sixtieth agent on the fabric — audit-log-integrity-agent, a DETERMINISTIC (no-Claude) control-plane / data-substrate service on the platform plane, reusing the existing data-plane tier (planeForTier('data-plane') === 'platform') as a SIBLING to the Consent & Preferences Management, Master Patient Index, Break-the-Glass, Data Retention, De-Identification, and Minimum Necessary agents — it does NOT invent a new tier or plane, and it caps the PLATFORM & DATA SUBSTRATE story with the meta-guarantee: every agent on the fabric writes a HIPAA audit span, and THIS agent verifies the audit TRAIL itself is tamper-evident. It COMPLEMENTS, not duplicates, the other platform agents: distinct from the Consent & Preferences Management agent (WHETHER a patient may be contacted / data used), the De-Identification & Safe Harbor agent (whether a dataset is no longer PHI), the Minimum Necessary agent (HOW MUCH PHI a purpose may see), the Master Patient Index (identity / dedup), the Break-the-Glass agent (emergency PHI access), and the Data Retention agent (records disposition), this verifies that the AUDIT TRAIL of everything the fabric did has not been tampered with. It is a DETERMINISTIC, no-Claude agent: in a new pure lib/audit-log-integrity.ts, evaluateAuditLogIntegrity(request) takes an audit log (an ordered list of entries, each with a sequence number, actor, action, target, timestamp, the prior entry's hash, and its own hash) and DETERMINISTICALLY recomputes each entry's hash (a small dependency-free non-cryptographic FNV-1a so the chain is isomorphic across the node route, the browser panel, and the tests), verifies each chain link (the entry's prevHash against the prior entry's recomputed hash, chaining from a genesis), checks the sequence numbers for gaps, and decides whether the log is VERIFIED (hash chain intact AND sequence complete). Verification is a pure function of the log's entries (no randomness, no clock — NO Date.now()), so the same log always yields the same verified / hash-chain / sequence result. A determination — verified OR tamper-suspected — is a SAFE, honest OUTPUT: the task COMPLETES (a tampered / incomplete log carries requiresForensicReview:true), which is how a legitimate determination is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Minimum Necessary and De-Identification agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.auditlog.hash-chain-verified (signal auditLogHashChainVerified, violating value false) blocks a determination that marks a log VERIFIED while its hash chain is not intact (a recomputed hash or a prevHash link does not match — a single broken link is tampering, and a verified label over a broken chain HIDES it) — backed by the pure guard auditLogHashChainVerified (mirroring the Minimum Necessary Agent's minimum-necessary-scoped posture — an integrity obligation that cannot be skipped); policy.auditlog.sequence-complete (signal auditLogSequenceComplete, violating value false) blocks a determination that marks a log VERIFIED while its sequence has a gap (a gap means an entry was deleted — which the hash chain alone would not catch at the tail — and a verified label over a gap HIDES the deleted record) — the load-bearing completeness gate — backed by the guard auditLogSequenceComplete; and policy.auditlog.no-autonomous-redaction (signal auditLogNoAutonomousRedaction, violating value false) blocks a determination that claims it repaired / rewrote / re-sealed the log — the agent VERIFIES and FLAGS, it NEVER deletes, rewrites, or repairs an audit entry (that would destroy evidence), and a broken log is flagged for human forensic review — backed by the guard auditLogNoAutonomousRedaction (mirroring the Data Retention Agent's no-autonomous-purge and the Minimum Necessary Agent's no-autonomous-over-disclosure posture; the harmful action is enforced-off). It also reuses, by extending appliesTo, the HIPAA-audit policy (it is PHI-bearing — audit entries reference patient targets), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/audit-log-integrity/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — auditlog.receive-log → auditlog.verify → auditlog.attest → auditlog.log-audit — with phiAccessed:true, returning the AuditLogDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Audit Log Integrity panel (an intact 5-entry preset → verified, no forensic review; an altered-entry preset → the tampered entry's hash no longer matches, flagged for forensic review, NOT repaired; a deleted-entry preset → a sequence gap 3 → 5; plus verified-over-broken-chain / verified-with-sequence-gap / auto-repaired governance-block presets), a seeded auditlog.receive-log→verify→attest→log-audit trace showing a verified 5-entry log (0 broken links, 0 sequence gaps, phiAccessed:true), the console subtitle, and the investor brief (now 'sixty agents', with the Audit Log Integrity agent on the platform data-plane tier alongside the other substrate agents) all reflect it. Frontend tests green (2,649 tests — + audit-log hashing / sealing / verify / tamper / gap / determinism / three-signal-true-and-false guards, the route's envelope / three governance blocks / allow + tampered + gap happy paths, the panel's request-body + view-lift, and the registry + brief drift guards raised to sixty agents); the FNV-1a hash chain + sequence check are clearly-labeled illustrative synthetics, NOT a certified tamper-evidence system — a real control uses a cryptographic hash (SHA-256), append-only / WORM storage, and signed checkpoints. Lint + build clean.
Agent Fabric: added the Minimum Necessary (HIPAA) agent — deterministic purpose-of-use disclosure scoping with purpose-of-use-sourced, minimum-necessary-scoped, and never an autonomous over-disclosure (the 59th agent)
ShippedDetails
Added the fifty-ninth agent on the fabric — minimum-necessary-agent, a DETERMINISTIC (no-Claude) control-plane / data-substrate service on the platform plane, reusing the existing data-plane tier (planeForTier('data-plane') === 'platform') as a SIBLING to the Consent & Preferences Management, Master Patient Index, Break-the-Glass, Data Retention, and De-Identification agents — it does NOT invent a new tier or plane, and it rounds out the PLATFORM & DATA SUBSTRATE privacy story. It COMPLEMENTS, not duplicates, the other platform agents: distinct from the Consent & Preferences Management agent (WHETHER a patient may be contacted / data used for a scope), the De-Identification & Safe Harbor agent (whether a dataset is no longer PHI), the Master Patient Index (identity / dedup), the Break-the-Glass agent (emergency PHI access), and the Data Retention agent (records disposition), this decides HOW MUCH of an identified patient's PHI a given purpose-of-use may see. It is a DETERMINISTIC, no-Claude agent: in a new pure lib/minimum-necessary.ts, evaluateMinimumNecessary(request) takes a disclosure request (a requestor role, a purpose-of-use, the specific fields requested — each mapped to a field CATEGORY — and the record scope: single-patient / cohort / bulk) and DETERMINISTICALLY resolves the governing purpose-of-use rule from a PURPOSE_RULES catalog (treatment, payment, healthcare-operations, research, marketing), then decides per field whether its category is within the minimum-necessary scope for that purpose (release) or beyond it (withhold), yielding a disclosure limited to the minimum necessary (45 CFR 164.502(b) / 164.514(d)). Treatment / disclosure-to-the-individual / authorized / required-by-law purposes are EXEMPT from the standard (all fields released). The determination is a pure function of the request + the purpose catalog (no randomness, no clock — time taken as data, NO Date.now()), so the same request always yields the same field decisions + released/withheld sets + flags. A determination — minimum-necessary or narrowed — is a SAFE, honest OUTPUT: the task COMPLETES (a narrowed / bulk disclosure carries requiresHumanReview:true), which is how a legitimate determination is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the De-Identification and Balance Billing agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.minnec.purpose-of-use-sourced (signal minNecPurposeSourced, violating value false) blocks a determination that cites no recorded purpose-of-use (an ad-hoc / un-sourced disclosure, a missing or off-catalog purpose id) — backed by the pure guard minNecPurposeSourced (mirroring the De-Identification Agent's method-cited and the Data Retention Agent's schedule-sourced posture); policy.minnec.minimum-necessary-scoped (signal minNecScoped, violating value false) blocks a determination that RELEASES a field whose category is beyond what the stated purpose-of-use permits — no field beyond the minimum necessary may be disclosed; releasing an out-of-scope field over-discloses PHI (this is the load-bearing privacy gate, mirroring the De-Identification Agent's no-release-of-reidentifiable — a privacy obligation that cannot be skipped) — backed by the guard minNecScoped; and policy.minnec.no-autonomous-over-disclosure (signal minNecNoAutonomousOverDisclosure, violating value false) blocks a determination that is not-minimum-necessary as submitted (fields had to be withheld) or that is a bulk / cohort disclosure but does not require human review — an over-scope or bulk disclosure is a RECOMMENDATION requiring human review, never autonomously released — backed by the guard minNecNoAutonomousOverDisclosure (mirroring the De-Identification Agent's no-release-of-reidentifiable and the Balance Billing Agent's no-autonomous-balance-bill posture; the harmful action is enforced-off). It also reuses, by extending appliesTo, the HIPAA-audit policy (it is PHI-bearing — it scopes patient PHI disclosures), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/minimum-necessary/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — minnec.receive-request → minnec.scope → minnec.decide → minnec.log-audit — with phiAccessed:true, returning the MinimumNecessaryDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Minimum Necessary panel (a payment-with-clinical-note preset → the note withheld as out-of-scope, human review; a payment-in-scope preset → all released, no review; a treatment preset → exempt, all released; a research-cohort preset → in-scope but bulk, human review; plus un-sourced-purpose / out-of-scope-release / over-scope-auto-approved governance-block presets), a seeded minnec.receive-request→scope→decide→log-audit trace showing a narrowed payment disclosure (4 released, 1 withheld, requiresHumanReview:true, phiAccessed:true), the console subtitle, and the investor brief (now 'fifty-nine agents', with the Minimum Necessary agent on the platform data-plane tier alongside the other substrate agents) all reflect it. Frontend tests green (2,619 tests — + minimum-necessary purpose-catalog / scoping / exempt / bulk / determinism / three-signal-true-and-false guards, the route's envelope / three governance blocks / allow + treatment-exempt happy paths, the panel's request-body + view-lift, and the registry + brief drift guards raised to fifty-nine agents); the purpose-of-use catalog, requestor roles, field categories, and allowed-category mappings are clearly-labeled illustrative synthetics, NOT a certified minimum-necessary engine — a real determination uses the covered entity's role-based access policies and its minimum-necessary standard under 45 CFR 164.502(b) / 164.514(d). Lint + build clean.
Agent Fabric: added the Immunization Forecasting (ACIP) agent — deterministic vaccine forecasting with schedule-sourced, contraindication-honored, and never an autonomous administration (the 58th agent)
ShippedDetails
Added the fifty-eighth agent on the fabric — immunization-agent, a DETERMINISTIC (no-Claude) clinical-decision service on the patient & clinical plane, reusing the existing clinical-decision tier (planeForTier('clinical-decision') === 'patient-care') as a SIBLING to the Care Router, Care Plan, Prior Authorization, and Lab Result agents — it does NOT invent a new tier or plane, and it deliberately broadens the CLINICAL side of the fabric (recent additions had leaned payer / data-substrate). It COMPLEMENTS, not duplicates, the other clinical / care agents: distinct from the Care Gap Closure agent (broad missing preventive measures), the Lab Result agent (discrete diagnostic results), the Care Plan agent (the longitudinal plan), and the Care Router (triage), this forecasts the specific vaccine SCHEDULE — dose series, booster intervals, and age-eligibility — against ACIP-style rules. It is a DETERMINISTIC, no-Claude agent: in a new pure lib/immunization.ts, evaluateImmunization(request) takes a patient (a synthetic reference, a birth date, an immunization history, and any recorded contraindications) evaluated against a provided asOfDate, DETERMINISTICALLY computes the patient's age, and forecasts each vaccine (up-to-date / due / overdue / contraindicated / not-indicated) against an ACIP_SCHEDULE catalog (influenza annual, Td/Tdap booster every 10 years, recombinant zoster/RZV 2-dose series at 50+, pneumococcal at 65+, updated COVID-19), applying age-eligibility, dose-series / booster-interval logic, and any recorded contraindications, citing the governing schedule rule + the next-due date. The forecast is a pure function of the request + its own asOfDate + the schedule catalog (no randomness, no clock — time taken as data, NO Date.now()), so the same patient always yields the same forecast + cited rules + next-due dates. A forecast — with due / overdue vaccines — is a SAFE, honest OUTPUT: the task COMPLETES (due / overdue vaccines carry requiresClinicianOrder:true), which is how a legitimate forecast is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Lab Result and Balance Billing agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.immunization.schedule-sourced (signal immunizationScheduleCited, violating value false) blocks a vaccine recommendation that cites no recorded ACIP schedule rule (an ad-hoc / un-sourced recommendation, a missing or off-catalog rule id) — backed by the pure guard immunizationScheduleCited (mirroring the Lab Result Agent's reference-range-sourced and the Data Retention Agent's schedule-sourced posture); policy.immunization.contraindication-honored (signal immunizationContraindicationHonored, violating value false) blocks a forecast that RECOMMENDS (due / overdue) a vaccine for which the patient has a recorded contraindication — a contraindicated vaccine must be withheld and flagged, never recommended; recommending it is a patient-safety hazard (this is the load-bearing safety gate, mirroring the Lab Result Agent's critical-value-notified — a clinical-safety obligation that cannot be skipped) — backed by the guard immunizationContraindicationHonored; and policy.immunization.no-autonomous-administration (signal immunizationNoAutonomousAdministration, violating value false) blocks a determination that reports due / overdue vaccines but does not require a clinician order — a due / overdue vaccine is a RECOMMENDATION requiring a clinician order, and the agent never administers, orders, or records a vaccine autonomously — backed by the guard immunizationNoAutonomousAdministration (mirroring the Lab Result Agent's no-autonomous-clinical-action and the Balance Billing Agent's no-autonomous-balance-bill posture; the harmful action is enforced-off). It also reuses, by extending appliesTo, the HIPAA-audit policy (it is PHI-bearing — it forecasts patient immunizations), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/immunization/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — immunization.receive-patient → immunization.forecast → immunization.recommend → immunization.log-audit — with phiAccessed:true, returning the ImmunizationDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Immunization panel (a 52-year-old preset → flu up-to-date, Tdap + zoster overdue, pneumococcal not-indicated, COVID due, requiring a clinician order; a zoster-contraindicated preset → withheld / never recommended; a 40-year-old preset → all up-to-date; plus off-catalog-rule / recommended-contraindicated / due-without-clinician-order governance-block presets), a seeded immunization.receive-patient→forecast→recommend→log-audit trace showing a midlife patient's forecast (1 due + 2 overdue, requiresClinicianOrder:true, phiAccessed:true), the console subtitle, and the investor brief (now 'fifty-eight agents', with the Immunization agent on the clinical-decision tier alongside the Care Router, Care Plan, Prior Authorization, and Lab Result agents) all reflect it. Frontend tests green (2,590 tests — + immunization schedule-catalog / forecast / contraindication / determinism / three-signal-true-and-false guards, the route's envelope / three governance blocks / allow + contraindicated-withheld happy paths, the panel's request-body + view-lift, and the registry + brief drift guards raised to fifty-eight agents); the ACIP-style schedule, age-eligibility, dose series, and booster intervals are clearly-labeled illustrative synthetics, NOT a certified immunization forecaster — a real forecast uses the current ACIP recommendations, the CDC immunization schedules, and the patient's full clinical context. Lint + build clean.
Agent Fabric: added the De-Identification & Safe Harbor agent — deterministic HIPAA Safe Harbor screening with all-eighteen-categories-screened, method-cited, and never a re-identifiable release (the 57th agent)
ShippedDetails
Added the fifty-seventh agent on the fabric — deidentification-agent, a DETERMINISTIC (no-Claude) control-plane / data-substrate service on the platform plane, reusing the existing data-plane tier (planeForTier('data-plane') === 'platform') as a SIBLING to the Consent & Preferences Management, Master Patient Index, Break-the-Glass, and Data Retention agents — it does NOT invent a new tier or plane, and it deliberately broadens the PLATFORM & DATA SUBSTRATE (which recent additions had not touched) rather than piling onto the payer / patient-access side. It COMPLEMENTS, not duplicates, the other platform agents: distinct from the Consent & Preferences Management agent (patient consent scopes for outreach / data-sharing), the Master Patient Index (identity / dedup), the Break-the-Glass agent (emergency PHI access), the Data Retention agent (records disposition), and the Data-Sharing / TEFCA agent (interoperability exchange), this decides whether a dataset is DE-IDENTIFIED (no longer PHI) under HIPAA Safe Harbor before a secondary use / disclosure. It is a DETERMINISTIC, no-Claude agent: in a new pure lib/deidentification.ts, evaluateDeidentification(request) takes a dataset described by its FIELDS (each a name, the Safe Harbor identifier category it maps to — or non-identifier — and the action taken: removed / generalized / retained), the chosen METHOD (safe-harbor or expert-determination), the categories attested absent, and (for expert determination) the cited determination reference, and DETERMINISTICALLY screens the dataset against the EIGHTEEN HIPAA Safe Harbor identifier categories (45 CFR 164.514(b)(2)(i)(A)–(R) — names, geographic, dates, phone, fax, email, SSN, MRN, health-plan-id, account, certificate/license, vehicle, device, URL, IP, biometric, photo, and any-other-unique), computes which categories remain identifiable after the field actions (a retained identifier, or a generalization that does not satisfy Safe Harbor — only geographic → first three ZIP digits and dates → year only qualify, every other category must be removed), computes whether all eighteen categories were screened (present as a field or attested absent), validates the method citation, and decides whether the dataset qualifies as de-identified: de-identified iff a recognized method is cited, all eighteen categories were screened, and no identifier category remains. The determination is a pure function of the dataset's fields + the category catalog (no randomness, no clock — NO Date.now()), so the same dataset always yields the same de-identification decision + remaining categories + release flag. A determination — de-identified or NOT — is a SAFE, honest OUTPUT: the task COMPLETES (a not-de-identified dataset carries requiresHumanReview:true and releaseApproved:false), which is how a legitimate determination is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Balance Billing and Data Retention agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.deid.all-categories-screened (signal deidAllCategoriesScreened, violating value false) blocks a determination whose screen SKIPPED a Safe Harbor category (a category neither present as a field nor attested absent) — an incomplete screen may hide a re-identifying identifier, so a dataset cannot be claimed de-identified without accounting for every category (this is the load-bearing completeness gate, mirroring the Good Faith Estimate Agent's expected-items-complete and the Lab Result Agent's critical-value-notified — a completeness obligation that cannot be skipped) — backed by the pure guard deidAllCategoriesScreened; policy.deid.method-cited (signal deidMethodCited, violating value false) blocks an ad-hoc / un-cited de-identification that names no recognized method — neither HIPAA Safe Harbor (§164.514(b)(2)) nor a qualified Expert Determination with a cited determination reference (§164.514(b)(1)) — backed by the guard deidMethodCited (mirroring the Data Retention Agent's schedule-sourced and the Balance Billing Agent's protection-basis-sourced posture); and policy.deid.no-release-of-reidentifiable (signal deidNoReleaseOfReidentifiable, violating value false) blocks a determination that marks a dataset de-identified / release-approved while an identifier category still REMAINS (a retained identifier, or a generalization that does not satisfy Safe Harbor) — a re-identifiable dataset is NOT de-identified and may never be released as de-identified; releasing re-identifiable data requires human review under a data use agreement — backed by the guard deidNoReleaseOfReidentifiable (mirroring the Balance Billing Agent's no-autonomous-balance-bill and the Master Patient Index Agent's no-autonomous-merge posture; the harmful action is enforced-off). It also reuses, by extending appliesTo, the HIPAA-audit policy (it is PHI-bearing — it screens patient datasets), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/deidentification/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — deid.receive-dataset → deid.screen → deid.determine → deid.log-audit — with phiAccessed:true, returning the DeidentificationDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new De-Identification panel (a Safe Harbor scrub preset → de-identified / release approved, an expert-determination-with-cited-ref preset → de-identified, an MRN-retained preset → not de-identified / release withheld, an incomplete-screen preset → not de-identified, plus incomplete-screen-marked-de-identified / no-cited-method / re-identifiable-release governance-block presets), a seeded deid.receive-dataset→screen→determine→log-audit trace showing a fully-scrubbed Safe Harbor dataset (18/18 categories screened, 0 remaining identifiers, release approved, phiAccessed:true), the console subtitle, and the investor brief (now 'fifty-seven agents', with the De-Identification agent on the platform data-plane tier alongside the other substrate agents) all reflect it. Frontend tests green (2,562 tests — + de-identification catalog / screen / method / generalization / determinism / three-signal-true-and-false guards, the route's envelope / three governance blocks / allow + not-de-identified happy paths, the panel's request-body + view-lift, and the registry + brief drift guards raised to fifty-seven agents); the Safe Harbor category catalog + generalization rules are clearly-labeled illustrative synthetics, NOT a certified de-identification engine — a real determination applies the full Safe Harbor method (including the actual-knowledge clause) or a qualified statistician's Expert Determination under 45 CFR 164.514(b). Lint + build clean.
Agent Fabric: added the Balance Billing Protection (No Surprises Act) agent — deterministic claim-time protection with protection-basis-sourced, in-network (QPA) cost-share basis, and never an autonomous balance bill (the 56th agent)
ShippedDetails
Added the fifty-sixth agent on the fabric — balance-billing-agent, a DETERMINISTIC (no-Claude) payer & plan operations service on the PHI-bearing payer plane, reusing the existing payer-operations tier as a SIBLING to the Claims Adjudication, Coordination of Benefits, Overpayment & Recovery, Utilization Review, and FWA agents — it does NOT invent a new tier or plane, and it is the CLAIM-time complement to the patient-access Good Faith Estimate agent (the two sides of the No Surprises Act: the provider-estimate side and the payer/claims side). It COMPLEMENTS, not duplicates, the other payer agents: distinct from Claims Adjudication (per-claim edits), Coordination of Benefits (payer ORDER), Overpayment & Recovery (POST-payment clawback), Utilization Review (medical necessity), and FWA (fraud) — this decides, at claim time, whether the No Surprises Act PROHIBITS balance-billing an out-of-network claim and on what basis a protected patient's cost-share is computed. It is a DETERMINISTIC, no-Claude agent: in a new pure lib/balance-billing.ts, evaluateBalanceBilling(request) takes a claim (its protection basis — the service setting / provider network status — plus the service type, whether it is an ancillary service, the billed charge, the in-network allowed / Qualifying Payment Amount, and whether a valid notice-and-consent waiver was obtained) and DETERMINISTICALLY resolves the protection basis from a PROTECTION_BASES catalog (emergency, out-of-network at an in-network facility, air ambulance, ground ambulance, in-network), applies any EFFECTIVE waiver (valid only for a waivable, non-ancillary service — ancillary services like anesthesiology / radiology / pathology can NEVER be waived), decides whether the patient is PROTECTED, computes the patient's cost-share BASIS (the in-network QPA for a protected claim, never the out-of-network billed charge), and computes the balance-bill amount (0 + prohibited for a protected claim; billedCharge − allowed for a permitted one). Protection applies to emergency services, an out-of-network provider at an in-network facility, and air ambulance; an out-of-network ground ambulance is NOT protected (a known NSA gap). The determination is a pure function of the request + the basis catalog (no randomness, no clock — time taken as data, NO Date.now()), so the same claim always yields the same protection + cost-share basis + balance-bill flags. A determination — protected or not — is a SAFE, honest OUTPUT: the task COMPLETES (a permitted balance bill on a NON-protected claim carries requiresHumanReview:true), which is how a legitimate determination is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Overpayment & Recovery and Good Faith Estimate agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.balancebill.protection-basis-sourced (signal balanceBillBasisCited, violating value false) blocks an ad-hoc / un-sourced protection call that doesn't cite a recorded protection basis (a missing or off-catalog basis id) — backed by the pure guard balanceBillBasisCited (mirroring the Overpayment & Recovery agent's reason-catalog-sourced and the Good Faith Estimate agent's charge-master-sourced posture); policy.balancebill.cost-share-in-network-basis (signal balanceBillCostShareInNetwork, violating value false) blocks a determination that bases a PROTECTED patient's cost-share on the out-of-network billed charge instead of the in-network (QPA) basis — basing it on the billed charge OVER-CHARGES the patient, and the No Surprises Act (45 CFR 149.110–149.130) requires cost-sharing for a protected service to be based on the recognized amount (the QPA) (this is the load-bearing gate, mirroring the Overpayment & Recovery agent's within-lookback-window — a legal basis bounds the dollar figure) — backed by the guard balanceBillCostShareInNetwork; and policy.balancebill.no-autonomous-balance-bill (signal balanceBillProhibitionHonored, violating value false) blocks a determination that ALLOWS a balance bill on a PROTECTED claim — a protected claim can NEVER be balance-billed (the difference between the billed charge and the allowed amount may not be billed to the patient, and a balance bill is never issued autonomously against a protected patient); a permitted balance bill on a NON-protected claim (a valid waiver, an out-of-network ground ambulance) is a RECOMMENDATION requiring human review — backed by the guard balanceBillProhibitionHonored (mirroring the Overpayment & Recovery agent's no-autonomous-clawback and the Lab Result agent's no-autonomous-clinical-action posture). It also reuses, by extending appliesTo, the HIPAA-audit policy (it is PHI-bearing — a payer-operations agent), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/balance-billing/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — balancebill.receive-claim → balancebill.evaluate → balancebill.recommend → balancebill.log-audit — with phiAccessed:true, returning the BalanceBillingDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Balance Billing Protection panel (an OON emergency preset → protected / in-network cost-share / no balance bill, an OON anesthesiology (ancillary) preset → protected (cannot be waived), an OON elective-surgery + valid-waiver preset → permitted balance bill requiring review, an OON ground-ambulance preset → not protected / permitted balance bill, plus no-cited-basis / protected-on-billed-charge / balance-bill-on-protected governance-block presets), a seeded balancebill.receive-claim→evaluate→recommend→log-audit trace showing a protected out-of-network emergency (cost-share on the $1,200 in-network QPA, balance billing prohibited, phiAccessed:true), the console subtitle, and the investor brief (now 'fifty-six agents', with the Balance Billing agent on the payer-operations tier alongside the other payer agents) all reflect it. Frontend tests green (2,530 tests — + balance-billing catalog / protection / waiver / cost-share-basis / determinism / off-catalog / three-signal-true-and-false guards, the route's envelope / three governance blocks / allow + permitted-bill happy paths, the panel's request-body + view-lift, and the registry + brief drift guards raised to fifty-six agents); the protection bases, waiver rules, ancillary handling, and QPA amounts are clearly-labeled illustrative synthetics, NOT a certified No Surprises Act engine — a real determination uses the actual Qualifying Payment Amount, the federal Independent Dispute Resolution process, the notice-and-consent requirements, and the provider's network contracts under 45 CFR 149. Lint + build clean.
Agent Fabric: added the Good Faith Estimate (No Surprises Act) agent — deterministic itemized self-pay estimate with charge-master-sourced pricing, expected-items-complete, and estimate-not-binding (the 55th agent)
ShippedDetails
Added the fifty-fifth agent on the fabric — good-faith-estimate-agent, a DETERMINISTIC (no-Claude) patient-access service on the PHI-bearing patient & clinical plane, reusing the existing benefits-verification (patient-access) tier (planeForTier('benefits-verification') === 'patient-care') as a SIBLING to the Benefits & Coverage Verification (EBV) and Patient Financial Assistance & Charity Care agents — it does NOT invent a new tier or plane, and it completes the patient-access financial TRIAD: plan eligibility (EBV) → itemized self-pay estimate (this) → charity screening (Financial Assistance). It COMPLEMENTS, not duplicates, its siblings: the EBV agent verifies what the PLAN covers (eligibility + the estimated COVERED visit cost) and the Financial Assistance agent screens the patient-responsibility remainder for CHARITY CARE — this assembles the itemized SELF-PAY / uninsured estimate of expected charges required BEFORE care under the No Surprises Act. It is a DETERMINISTIC, no-Claude agent: in a new pure lib/good-faith-estimate.ts, evaluateGoodFaithEstimate(request) takes a scheduled primary service + the expected line items (each a charge-master service id + quantity) and DETERMINISTICALLY prices each line item from an illustrative CHARGE_MASTER (established visit $220, comprehensive menopause consult $400, hormone panel $180, DEXA $250, pelvic ultrasound $450, HRT admin $90), verifies the estimate includes the primary service AND every reasonably-expected co-item from EXPECTED_COITEMS (a comprehensive consult expects a hormone panel; a DEXA / pelvic ultrasound expects an ordering office visit), sums the total expected charge, and returns a Good Faith Estimate that is an ESTIMATE (binding:false) requiring patient confirmation, with the No Surprises Act $400 dispute threshold recorded (if the actual bill exceeds the GFE by $400 or more the patient has dispute rights). The estimate is a pure function of the request's line items + the charge master (no randomness, no clock — time taken as data, NO Date.now()), so the same request always yields the same total + completeness + sourcing flags. A GFE is a SAFE, honest OUTPUT: the task COMPLETES (binding:false, requiresPatientConfirmation:true), which is how a legitimate estimate is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Lab Result and Patient Financial Assistance agents' output-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.gfe.charge-master-sourced (signal gfeChargeMasterSourced, violating value false) blocks a determination with a line item that is NOT charge-master-sourced (an off-catalog service id or an amount that doesn't match the charge master — an ad-hoc / fabricated charge) — backed by the pure guard gfeChargeMasterSourced (mirroring the Overpayment & Recovery Agent's reason-catalog-sourced and the Lab Result Agent's reference-range-sourced posture); policy.gfe.expected-items-complete (signal gfeExpectedItemsComplete, violating value false) blocks an INCOMPLETE estimate that omits the primary service or a reasonably-expected co-item — an incomplete estimate UNDERSTATES the total and misleads the patient, and the No Surprises Act (45 CFR 149.610) requires the convening provider to include items/services reasonably expected to be furnished (this is the load-bearing gate, mirroring the Care Coordination Handoff Agent's SBAR-completeness and the Lab Result Agent's critical-value-notified — a completeness obligation that cannot be skipped) — backed by the guard gfeExpectedItemsComplete; and policy.gfe.estimate-not-binding (signal gfeEstimateNotBinding, violating value false) blocks a determination presented as a BINDING / final bill (binding:true) — a GFE is an ESTIMATE requiring patient confirmation, never a final charge — backed by the guard gfeEstimateNotBinding (mirroring the Lab Result Agent's no-autonomous-clinical-action and the Financial Assistance Agent's no-autonomous-denial posture; the agent recommends, a human confirms). It also reuses, by extending appliesTo, the HIPAA-audit policy (it is PHI-bearing — a patient-access agent), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/good-faith-estimate/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — gfe.receive-request → gfe.price → gfe.assemble → gfe.log-audit — with phiAccessed:true, returning the GoodFaithEstimateDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Good Faith Estimate panel (a complete-consult preset → $580, a complete-imaging DEXA preset → $470, plus off-catalog-charge / missing-item / binding-bill governance-block presets), a seeded gfe.receive-request→price→assemble→log-audit trace showing a complete $580 consult estimate (phiAccessed:true), the console subtitle, and the investor brief (now 'fifty-five agents', with the Good Faith Estimate agent on the patient-access tier alongside EBV + Financial Assistance) all reflect it. Frontend tests green (2,499 tests — + good-faith-estimate charge-master / pricing / completeness / determinism / three-signal-true-and-false guards, the route's envelope / three governance blocks / allow happy path, the panel's request-body + view-lift, and the registry + brief drift guards raised to fifty-five agents); the charge master, categories, amounts, and expected-co-item rules are clearly-labeled illustrative synthetics, NOT a certified hospital chargemaster, machine-readable price-transparency file, or a real provider's charges — a real GFE is governed by the No Surprises Act (45 CFR 149.610), the provider's actual charges, and HHS guidance. Lint + build clean.
Agent Fabric: added the Lab Result & Critical-Value Notification agent — deterministic result classification with critical-value-notified, reference-range-sourced, and no autonomous clinical action (the 54th agent)
ShippedDetails
Added the fifty-fourth agent on the fabric — lab-result-agent, a DETERMINISTIC (no-Claude) clinical-decision service on the PHI-bearing patient & clinical plane, reusing the existing clinical-decision tier (the Care Router / Care Plan / Prior Auth tier, planeForTier('clinical-decision') === 'patient-care') as a deterministic SIBLING to the live-Claude Care Router — it does NOT invent a new tier or plane, and it deliberately broadens the fabric into the CLINICAL side (the clinical-decision tier previously held only the Care Router + Care Plan + Prior Auth) rather than piling onto the payer / patient-financial side. It COMPLEMENTS, not duplicates, the other clinical / care agents: distinct from the Remote Patient Monitoring agent (continuous wearable / RPM streams), the Clinical Summary agent (chart summarization), and the Care Gap Closure agent (missing preventive measures), this manages DISCRETE diagnostic LAB results + the critical-value notification workflow. It is a DETERMINISTIC, no-Claude agent: in a new pure lib/lab-result.ts, evaluateLabResult(request) takes a discrete diagnostic lab result (an analyte id + numeric value + unit, with the patient + ordering-provider references) and DETERMINISTICALLY classifies the value against the analyte's reference range + critical thresholds from a LAB_ANALYTES catalog (potassium, sodium, glucose, calcium, hemoglobin — the electrolyte / glucose / calcium / hemoglobin panel a midlife patient on HRT or under bone-health monitoring routinely has drawn) as normal / abnormal-high / abnormal-low / critical-high / critical-low, flags whether the result requires MANDATORY clinician notification (a critical / panic value) and whether it requires clinician review (any abnormal result); critical thresholds take precedence over the reference range. The classification is a pure function of the value + the analyte's catalog range (no randomness, no clock — time taken as data, NO Date.now()), so the same result always yields the same classification + notification + review flags. A classification — even a CRITICAL one — is a SAFE, honest OUTPUT: the task COMPLETES (a critical result carries requiresProviderNotification:true; any non-normal result carries requiresClinicianReview:true), which is how a legitimate result is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Patient Financial Assistance and Overpayment & Recovery agents' recommendation-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.lab.critical-value-notified (signal labCriticalValueNotified, violating value false) blocks a determination that asserts a CRITICAL (panic) value that does NOT require provider notification — a critical value is NEVER suppressed or auto-closed, because CLIA §493.1291(g) requires the laboratory to immediately alert the responsible provider (this is the load-bearing parallel to the Care Coordination Handoff agent's SBAR-completeness — a life-safety obligation that cannot be skipped) — backed by the pure guard labCriticalValueNotified; policy.lab.reference-range-sourced (signal labRangeCited, violating value false) blocks an ad-hoc / un-sourced result interpretation that doesn't cite a recorded analyte reference range (a missing or off-catalog analyte id) — backed by the guard labRangeCited (mirroring the Overpayment & Recovery agent's reason-catalog-sourced and the Data Retention agent's schedule-sourced posture); and policy.lab.no-autonomous-clinical-action (signal labClinicianReviewed, violating value false) blocks a determination that would autonomously ACT on a non-normal result (an abnormal / critical result not gated on clinician review) — the agent NEVER orders a test, prescribes, treats, or changes a care plan; every non-normal result is a flag escalated for clinician review (requiresClinicianReview:true) — backed by the guard labClinicianReviewed (mirroring the Utilization Review agent's no-autonomous-denial and the Risk Adjustment agent's no-autonomous-submission posture). It also reuses, by extending appliesTo, the HIPAA-audit policy (it is PHI-bearing — a clinical-decision agent), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/lab-result/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — lab.receive-result → lab.classify → lab.recommend → lab.log-audit — with phiAccessed:true, returning the LabResultDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Lab Result panel (a normal-potassium preset → no notification, a critical-high-potassium preset → mandatory notification, an abnormal-high-glucose preset → clinician review only, a critical-low-sodium preset → mandatory notification, plus suppress-critical / no-cited-range / autonomous-action governance-block presets), a seeded lab.receive-result→classify→recommend→log-audit trace showing a critical-high potassium (6.8 mmol/L, requiresProviderNotification:true, phiAccessed:true), the console subtitle, and the investor brief (now 'fifty-four agents', with the Lab Result agent on the clinical-decision tier alongside the Care Router) all reflect it. Frontend tests green (2,470 tests — + lab-result catalog / classification / determinism / off-catalog / three-signal-true-and-false guards, the route's envelope / three governance blocks / allow + normal happy paths, the panel's request-body + view-lift, and the registry + brief drift guards raised to fifty-four agents); the analyte catalog, reference ranges, units, and critical thresholds are clearly-labeled illustrative synthetics, NOT a certified laboratory information system or a CLIA-validated critical-value policy — real ranges are method-/instrument-/population-specific and set by each laboratory's medical director under CLIA (42 CFR 493) + CAP accreditation. Lint + build clean.
Agent Fabric: added the Patient Financial Assistance & Charity Care agent — deterministic 501(r) charity-care screening with no-collections-before-screening, FAP-schedule-sourced eligibility, and no autonomous denial (the 53rd agent)
ShippedDetails
Added the fifty-third agent on the fabric — financial-assistance-agent, a provider-side patient-financial-experience service on the PHI-bearing patient & clinical plane, reusing the existing benefits-verification tier as a SIBLING to the Benefits & Coverage Verification (EBV) agent (planeForTier('benefits-verification') === 'patient-care') — it does NOT invent a new tier or plane, and it deliberately balances the fabric toward the patient-access side rather than piling onto the payer plane. It COMPLEMENTS, not duplicates, the EBV agent: EBV verifies what the PLAN covers (eligibility + the estimated covered visit cost); this screens the PATIENT-RESPONSIBILITY remainder for CHARITY CARE — a different question — and is also distinct from the SDOH Screening agent (health-related social needs). It is a DETERMINISTIC, no-Claude agent: in a new pure lib/financial-assistance.ts, evaluateFinancialAssistance(request) takes a household size + annual income (plus the FPL guideline year, an optional presumptive-eligibility signal, whether the FAP application is complete, and whether an extraordinary collection action is being requested) and DETERMINISTICALLY computes the household's income as a percentage of the Federal Poverty Level (from the household size's FPL base in an illustrative FPL_TABLE + per-person increment), cites the governing FAP tier from an illustrative FAP_SCHEDULE (≤200% FPL → full charity 100% discount, 201–300% → 75%, 301–400% → 50%, >400% → not eligible), and classifies the patient as full-charity / partial-charity / not-eligible with a discount percentage under an IRS 501(r) Financial Assistance Policy; a recorded presumptive-eligibility reason (PRESUMPTIVE_REASONS — Medicaid-eligible, homelessness, SNAP-enrolled, deceased-no-estate) grants full charity regardless of documented income. The determination is a pure function of the household size + income + FPL year + the request's own flags (no randomness, no clock — time taken as data, NO Date.now()), so the same household always yields the same tier + discount + eligibility. GRANTING full or partial charity — and even a not-eligible determination — are SAFE, honest OUTPUTS: the task COMPLETES (a not-eligible determination carries requiresHumanReview:true and never an autonomous denial), which is how a legitimate recommendation is distinguished from a governance block (the block fires only on a caller-asserted DETERMINATION that violates a guard, mirroring the Overpayment & Recovery and Data Retention agents' recommendation-is-not-a-block posture). THREE load-bearing honesty properties are genuinely governance-enforced, each with its own NEW enforced-block policy + matching boolean signal wired into the shared governance-signals metadata: policy.finassist.no-eca-before-screening (signal ecaGatedOnScreening, violating value false) blocks a determination that asserts an extraordinary collection action (ECA — collections, credit reporting, a lien) while financial screening is NOT complete — under IRS 501(r)(6) a hospital must make reasonable efforts to determine FAP eligibility BEFORE any ECA (this is the load-bearing parallel to the Data Retention agent's legal-hold-overrides-purge and the Overpayment & Recovery agent's within-lookback-window: a legal precondition bounds the action) — backed by the pure guard ecaGatedOnScreening; policy.finassist.fap-schedule-sourced (signal finAssistScheduleCited, violating value false) blocks an ad-hoc / un-sourced eligibility decision that doesn't cite a recorded FAP tier — backed by the guard finAssistScheduleCited (mirroring the Data Retention agent's schedule-sourced and the Overpayment & Recovery agent's reason-catalog-sourced posture); and policy.finassist.no-autonomous-denial (signal finAssistHumanReviewed, violating value false) blocks a determination that would autonomously DENY charity care — a not-eligible determination is a RECOMMENDATION requiring human review with written notice + appeal rights under 501(r)(4) (requiresHumanReview:true) — backed by the guard finAssistHumanReviewed (mirroring the Overpayment & Recovery agent's no-autonomous-clawback, the Utilization Review agent's no-autonomous-denial, and the Claims Adjudication agent's no-autonomous-denial posture; granting charity is a benefit but denying it is legally consequential). It also reuses, by extending appliesTo, the HIPAA-audit policy (it is PHI-bearing — a patient-access agent, not a commercial-plane agent), and is deliberately NOT on the live-Claude model allow-list (no Claude). A runnable A2A endpoint (POST /api/agents/financial-assistance/tasks, JSON-RPC tasks/send validated with parseTasksSendEnvelope, a pre-flight governance gate, real parented trace spans — finassist.receive-application → finassist.evaluate → finassist.recommend → finassist.log-audit — with phiAccessed:true, returning the FinancialAssistanceDetermination as an artifact with metadata.agentFabric carrying the trace ids and the honesty signals, failed-task on a block) and a /.well-known/agent.json card whose policies derive from the registry round it out. It is surfaced on /demo/intake via a new Patient Financial Assistance panel (a full-charity preset → 100% discount, a partial-charity preset → 75% discount, a Medicaid presumptive-eligibility preset → full charity, a not-eligible preset → a denial requiring human review, plus eca-before-screening / no-cited-tier / autonomous-denial governance-block presets), a seeded finassist.receive-application→evaluate→recommend→log-audit trace showing a full-charity grant (household of 3 at 116% FPL, 100% discount, phiAccessed:true), the console subtitle, and the investor brief (now 'fifty-three agents', with the Patient Financial Assistance agent on the patient-access tier paired with the EBV agent) all reflect it. Frontend tests green (2,438 tests — + financial-assistance catalog / FPL-table / classification / determinism / ECA-gating / three-signal-true-and-false guards, the route's envelope / three governance blocks / allow + denial happy paths, the panel's request-body + view-lift, and the registry + brief drift guards raised to fifty-three agents); the FAP tier schedule, discount percentages, FPL table, and presumptive-eligibility reasons are clearly-labeled illustrative synthetics, NOT a certified financial-assistance system — real hospital FAPs are governed by IRS 501(r) / 26 CFR 1.501(r), the HHS Federal Poverty Guidelines, and each hospital's Board-approved FAP + state charity-care law. Lint + build clean.
