AxonFlow v10.1.0 Release Notes

v10.1.0 is the US compliance framework family. Three new compliance-report regulators land behind POST /api/v1/compliance/reports: usinsurance (the NAIC AI Systems Evaluation Tool's exhibit structure with New York and Colorado annexes), usbanking (the US federal banking and Farm Credit examination package), and ussecurities (the SEC/FINRA examination package for investment advisers and broker-dealers). Alongside them: nine US policy template families with regulator-keyed retention presets, a new jsonl artifact format offered to ussecurities alone, and a set of Community fixes, one of which changes who may call the audit-chain verification endpoints.

It is a MINOR by the semver policy. Everything is additive: five migrations run this release (core/168; enterprise/139, 142, 144, 145), none creates a table, none rewrites operator data destructively, none takes a long lock, and a community deployment applies only core/168. No capability is removed and no new configuration is required. One authorization change is worth reading before you upgrade rather than after: the three audit-chain verification routes now answer 403 for authenticated members whose role is not admin, owner or policy_admin. See Audit-chain verification becomes least-privilege.

Am I affected?

Anyone whose integrations call the audit-chain verification endpoints with a non-administrative identity. GET /api/v1/audit/chains/{id}/verify, GET /api/v1/audit/records/{id}/verify and GET /api/v1/audit/signing-key now require compliance read authority. A caller that traversed authentication but holds no entitled role starts receiving 403. Community mode is exempt; the hosted Community SaaS is deliberately not. Details under the Community section.

Anyone who applied a builtin policy template with a list-valued variable. Four shipped templates produced policies that could never fire, or fired on everything, including the values they were configured to allow. The templates are corrected at source and the affected already-seeded rows are repaired in place by migration. Read Policy templates that could not fire to understand what your deployment was and was not enforcing.

Anyone filtering the Policies page by category. Policies created by applying a template previously carried an empty category. New applications carry one, and rows applied before this release are backfilled where the application was recorded.

Enterprise operators who seeded compliance-gdpr or compliance-hipaa policy rows by SQL or a policy pack. Those categories were declared but filtered out before evaluation on every agent plane. They now evaluate. On a stock deployment nothing changes, because no shipped seed writes such rows and the API write paths reject compliance categories.

US institutions. The three new regulators, the template packs and the retention presets are the release. A deployment on v10.0.0 or earlier refuses all three regulators with 400 UNKNOWN_REGULATOR.

Community

Audit-chain verification becomes least-privilege

The audit-chain verification endpoints were readable by every authenticated organization member: GET /api/v1/audit/chains/{id}/verify, GET /api/v1/audit/records/{id}/verify and GET /api/v1/audit/signing-key were registered behind authentication and nothing else, so any member of an organization could verify, and thereby enumerate, its audit records by id. At its own severity: this is least-privilege and metadata disclosure, not a secret leak. The public key is public by definition, the per-record signature is meant to be shareable, no private key material was exposed, and the reads were already organization-scoped. What was reachable is each record's decision type, risk level and chain linkage, by roles that hold no tenant-wide audit read.

All three routes now require compliance read authority: a validated per-user token whose role is admin, owner or policy_admin, or an internal service asserting the X-Axonflow-Admin-Authority header. Holding the internal-service secret is the trusted channel, not the authority itself, so a service must assert it explicitly. The token is additionally bound to the credential's own organization and tenancy, which nothing previously checked: a privileged token from one organization presented with another organization's credential would otherwise have authorized a read scoped to the second. The gate is one middleware, so a verification route added later is gated by default.

Two deployment shapes to be precise about:

• Community mode is exempt, because it has no authentication under which to hold a role. Nothing changes there.
• The hosted Community SaaS is not exempt. It runs with authentication enabled, and its evaluator accounts hold no entitled role, so these three routes answer 403 there deliberately, rather than widening on a public shared deployment the exposure this change closes.

Policy templates that could not fire

Every builtin policy template with a list-valued variable produced a policy that could not work. A template writing "value": ["{{authorized_roles}}"] does not substitute to a list: the substitution walks into the array and returns the variable's value with its type preserved, so the result is an array nested inside an array, which the evaluator stringifies before comparing. An in condition written this way never fires, and a not_in condition always fires, so a policy meant to catch unauthorized roles instead matched every role including the authorized ones.

Four shipped templates carried the defect: HIPAA PHI Access Control and GDPR PII Access Control (both not_in, both over-matching), and DORA Critical Operations Monitoring and the community Content Safety Filter (both in, both inert). All are corrected at source, so every fresh deployment is right. Rows already seeded on existing deployments are forward-fixed by migration, by a targeted in-place update rather than delete-and-reseed, because deleting a template row would cascade away the record of who applied it. enterprise/139 repairs enterprise deployments; core/168 is the community-set repair for the Content Safety Filter row, since community deployments never apply enterprise migrations.

Policies created from templates now carry a category

Applying a template produced a policy with an empty category: unfilterable on the Policies page, and a row the direct-create API would have refused. The mapping is now the one-line prefix rule, dynamic- plus the template's catalog category (compliance-glba becomes dynamic-compliance-glba), so it is deterministic, passes the direct-create validation and preserves per-family filtering. core/168 backfills the category on policies applied before this release, via the recorded template-usage join. Empty-category rows from the bulk-import path have no usage record and are deliberately out of that backfill's scope.

Compliance policy categories now evaluate on every plane

The platform declared six compliance policy categories while the four agent plane whitelists (proxy, gateway pre-check, the OpenAI-compatible endpoint and the MCP input path) each hand-listed four of them. Because a plane whitelist filters the loaded policy set before evaluation, every compliance-gdpr and compliance-hipaa policy was dropped before it was ever evaluated: no error, no log, request allowed, while the portal advertised both as authorable categories. All four whitelists now source their compliance portion from the shared canonical list.

On a stock deployment the runtime delta is nil: no shipped seed has ever written a compliance-gdpr or compliance-hipaa row, and every API write path rejects compliance categories. The change becomes live only for rows seeded by SQL or a policy pack, where it removes a silent exclusion.

Enterprise

Three new compliance-report regulators

The compliance report facade grows from five regulators to eight. All three new ones follow the established rules: the framework field is required (each regulator reports against several instruments, and selecting one for the caller would file the artifact under a rule they did not choose), sections are always emitted even when empty, an unreadable source is disclosed rather than rendered as an empty result, and every artifact states what it deliberately does not claim.

usinsurance: the NAIC AI Systems Evaluation Tool. Renders the exhibit structure of the NAIC instrument formally titled "Artificial Intelligence Systems Evaluation: Optional Supplemental Exhibits for State Regulators", version 4.0 (DRAFT), from the NAIC Big Data and Artificial Intelligence (H) Working Group: Exhibit A (Quantify Regulated Entity's Use of AI Systems), Exhibit B (AI Systems Governance Risk Assessment Framework), Exhibit C (High Risk AI Systems Details), Exhibit D (AI Systems Model Data Details), plus annexes for NYDFS Insurance Circular Letter No. 7 and Colorado Regulation 10-1-1. The Tool is an examination information request that supplements market conduct, financial analysis and financial examination procedures; it is not an annual-statement filing. Frameworks: NAIC_AIS, NYDFS_CL7, CO_REG_10_1_1. Formats: pdf, csv, xlsx, json. Three read routes serve the portal's US insurance sections: GET /api/v1/usinsurance/inventory, GET /api/v1/usinsurance/oversight and GET /api/v1/usinsurance/data-sources, all GET-only, organization-scoped, and carrying an explicit completeness signal so an unreadable surface is never presented as an empty result.

usbanking: the US federal banking and Farm Credit examination package. Ten sections: scope and completeness, AI and agent inventory, per-decision reconstruction, human oversight register, kill-switch and containment attestation, data-boundary report, third-party AI annex, monitoring summary, board pack, and a NIST AI RMF cross-index. Frameworks: US_MRM, US_TPRM, GLBA_SAFEGUARDS, BSA_AML, FCA_EM31. Formats: pdf, csv, json. The report profile is derived from the framework, never requested: FCA_EM31 renders the Farm Credit profile (the FCA Exam Manual EM-31.1 when/what/who/approver change-log form for the oversight register, a quarterly board pack, and the 12 CFR Part 609 36-hour clock); the other four render the federal profile (SR 26-2 / OCC 2026-13 cited as current with SR 11-7 named as predecessor, and an annual cadence). A separate profile field would have made a self-contradicting request expressible, so the contradiction is made unrepresentable instead of validated. GET /api/v1/usbanking/exam-readiness answers what a package generated now would contain, without creating a report job and without spending one of an Evaluation tier's three daily reports; it returns counts, presence and disclosures, never evidence rows.

ussecurities: the SEC/FINRA examination package. One regulator for SEC-registered investment advisers and FINRA member broker-dealers, because the evidence set is identical and only the instrument each clause is cited against differs. Frameworks: SEC_EXAM, FINRA_SUPERVISION, REG_SP, and the supervised population is derived from the framework rather than requested: SEC_EXAM renders the adviser vocabulary, FINRA_SUPERVISION the broker-dealer vocabulary, and REG_SP reaches both, because the amended Regulation S-P applies to advisers and broker-dealers alike. Formats: pdf, csv, json and the new jsonl.

Eight sections, in the order the published AI sweep letters ask for them: the AI-use inventory with the reviewers AxonFlow actually observed resolving approval holds; the interaction archive; the consequential-output log; FINRA 3110 / Notice 24-09 supervision evidence; the amended Regulation S-P annex; the disclosure-vs-reality reconciliation; financial-crime evidence; and the scope, completeness and dated-instrument block.

The interaction archive carries the Ed25519 attribution chain in band: in the json and jsonl renderings each archived interaction carries its per-record signature, chain linkage and signing key id, so the export is independently verifiable record by record. The pdf and csv renderings carry the chain-head summary instead, and say so, naming the renderings that carry the full proof. Three states are kept apart, because collapsing any two of them is the defect the section exists to prevent: an interaction with no attribution record, one that is hash-chained but unsigned, and one that is signed. GET /api/v1/ussecurities/exam-readiness serves the portal's US securities section with counts, presence and disclosures only.

jsonl: a fifth artifact format, offered to ussecurities alone

Line-delimited JSON: one self-describing record per line, no enclosing array. A broker-dealer preserves records under Exchange Act rule 17a-4 on write-once read-many media or under the audit-trail alternative the 2022 amendments to that rule added, and the systems that ingest into either are line-oriented: they take a stream of records and commit each one, where a single JSON document has to be parsed whole first. Every line carries its schema, record type and job id, and every row record additionally carries the section key and the column headers its values are positional against, because line-oriented ingestion routinely splits a stream across batches. It is offered nowhere else, on the format matrix's own rule: a format is offered where the regulator's own practice wants it.

US policy templates and retention presets

A US institution's compliance team now finds US-native templates in the portal catalog the way Indian and Indonesian teams already do. Migration enterprise/139 seeds nine templates across four families:

• compliance-glba: NPI access logging and user-activity monitoring under 16 CFR 314.4(c)(8), and service-provider call gating under 16 CFR 314.4(f).
• compliance-fairlending: adverse-action decision logging and prohibited-basis prompt flags in Regulation B vocabulary (12 CFR 1002.9 and 1002.2(z)).
• compliance-bsa-aml: a SAR-confidentiality guard under 31 CFR 1020.320(e) and SAR-support retention logging under 31 CFR 1020.320(d). These extend the FinCrime Policy Pack rather than duplicating it: the pack's ten controls all govern transactions, and neither SAR control is among them.
• compliance-nydfs: NPI-in-prompt monitoring aligned to the NYDFS October 2024 AI industry letter, plus an AI-tool usage audit trail under 23 NYCRR 500.06(a)(2).

These are templates, not enforcing policies: a row is inert until an operator applies it, which is the right contract for a migration that runs on every enterprise deployment.

Retention presets are seeded into the existing defaults layer, the one that answers "what applies when nothing is configured", as five regulator-keyed record classes: Regulation B consumer-credit records at 25 months (12 CFR 1002.12(b)), SAR supporting documentation at 5 years (31 CFR 1020.320(d)), the two 23 NYCRR 500.06 record classes at 5 and 3 years, and SEC broker-dealer records at 6 years (17 CFR 240.17a-4(a)). There is deliberately no GLBA retention row: the Safeguards Rule requires the log and sets no period, and inventing one would be a fabricated regulatory number. The presets are a requirement vocabulary, not a pruning schedule: the retention executor iterates its own fixed table map, not the rows of this table, so a preset naming a record class AxonFlow does not store can never cause a delete. No new table, no new column, no new route.

Operator console fixes

The compliance console read the report facade's error code from the wrong field, so every code the facade emits was being classified by HTTP status alone, on all regulators; codes are now read from the field the facade writes. A regulator whose module is not wired in a deployment no longer renders as a retryable failure: the 409 REGULATOR_NOT_AVAILABLE answer reads as "not available on this deployment" instead of offering a Retry button for a condition retrying can never clear, while the facade's other two 409 codes keep their retry. And the licence refusal (403) and the daily report budget (429) are classified as plan answers carrying an upgrade path rather than as retryable failures.

What the US packages deliberately do not claim

Every one of these is stated on the face of the artifacts rather than left to be discovered, because on a document handed to an examiner an unearned claim is the worst available direction to be wrong in.

• AxonFlow provides no archival storage. Rule 17a-4 is satisfied by write-once read-many (WORM) media or by the audit-trail alternative the 2022 amendments to that rule added, and AxonFlow provides neither. The package is an export for whichever the firm operates; producing it preserves nothing. Every mention of WORM anywhere in the artifacts names the alternative beside it, because telling a firm it must hold WORM media is a false statement about a live obligation, and one that costs money to act on. On the adviser side the preservation rule is Advisers Act rule 204-2, never 17a-4.
• No statistical fairness, bias or disparate-impact testing is performed. The usinsurance fairness section is a pointer and contains no results; the quantitative analysis remains the carrier's own work. The usbanking package makes the same disclosure for the instruments that expect such testing.
• No output is classified as a recommendation. Whether an AI output triggers Regulation Best Interest or an adviser's fiduciary obligation is a legal judgment. No text classifier ships; the ussecurities consequential-output log renders the interactions a policy the firm configured as consequential stopped or held, and no section carries a recommendation or suitability column.
• Containment is manual. Kill-switch thresholds are persisted and reported, but nothing evaluates them automatically, so no automatic shutdown is claimed anywhere in any package. The containment the packages evidence is policy denial and approval holding.
• Coverage is what routed through AxonFlow. The packages report activity on AxonFlow's governed paths and perform no discovery of AI elsewhere in the institution. Nothing classifies a system's risk tier or analyses any law's applicability.
• Scope is stated per package. The usbanking and ussecurities packages are scoped to the requesting tenancy, because their sources are platform tables whose organization attribution is nullable, and an organization-wide predicate would silently omit records from a regulatory artifact; each package's completeness section reports how many records in the period carry no organization attribution, which is exactly the population an organization-wide report would have dropped without saying so. The ussecurities package states two exceptions on the artifact: the approval queue and the decision chain are additionally organization-bounded because the database enforces that boundary, and the configured supervisory controls are organization-scoped outright because that is the scope the enforcing engine reads them under. The usinsurance exhibits are organization-scoped. On a single-tenancy organization the scopes describe the same set of records.
• The ussecurities disclosure-vs-reality reconciliation adjudicates nothing. Its observed column is filled from measured evidence with each cell naming the section it is drawn from; its declared column is empty by construction, because AxonFlow holds no register of a firm's public AI claims. A firm completes the declared column from its own Form ADV, brochure and marketing materials. The table makes no finding that any claim is accurate, inaccurate or misleading.
• The financial-crime section is disclosed absent, never rendered empty, where the Fraud and Risk Add-on is not installed. An empty section would read as a statement about the firm; "the add-on is not active here" is a statement about the deployment. The risk score itself is never printed, and no suspicious activity report is implied or produced.
• The NAIC form revision is named on every usinsurance artifact. The Supplement was in pilot when this release was built and the adopted form may differ; confirm the exhibit structure against the form your domiciliary regulator has adopted before filing.

Migration

Five migrations run this release, all additive: core/168 and enterprise/139, 142, 144, 145. None creates a table, none rewrites operator data destructively, none takes a long lock. A community deployment applies only core/168. The migration runner sorts every selected category into one version-and-name order, so the enterprise widenings apply in numeric sequence.

• core/168 repairs the inert community Content Safety Filter row in place (one guarded in-place update on the seeded row) and backfills the category on policies applied from templates before this release, via the recorded template-usage join. Idempotent; its verification is scoped to the rows it owns.
• enterprise/139 seeds the nine US policy templates and five retention presets, and forward-fixes the four already-seeded templates broken by the list-variable substitution defect, by an in-place update on the exact path rather than delete-and-reseed, so the record of who applied what survives.
• enterprise/142 widens the report jobs table's regulator and framework CHECK constraints to admit usinsurance and its three frameworks. Additive only; no existing value is removed. Its down-migration refuses to run while any US insurance report row still exists, rather than deleting compliance evidence on the operator's behalf, and names the row count and the decision required.
• enterprise/144 widens the same constraints to admit usbanking and its five frameworks. The usbanking module itself adds no schema at all: it reads the audit trail, the approval queue and the provider inventory read-only, and needs no new index.
• enterprise/145 admits ussecurities, its three frameworks and the jsonl format, and is the current tail of the shared constraint-widening chain: it enumerates the full union at this release (eight regulators, nineteen frameworks, five formats) and verifies a value from every preceding widening. Its down-migration refuses to run while any US securities report row exists, for the same reason as enterprise/142.

From older versions: v10.1.0 is cumulative. If you are upgrading from v9.x, read the v10.0.0 release notes first: that release runs eight migrations, two of them whole-table rewrites of the audit log, and carries the breaking changes; the v9 to v10 migration guide sizes them. Nothing in v10.1.0 changes that sizing.

SDK and plugin compatibility

No SDK or plugin release accompanies this train. The recommended client versions are unchanged from v10.0.0: Go SDK v9.1.1, Python, TypeScript and Java SDKs v9.1.0, Rust SDK v0.8.2 (preview), and all five plugins at their v10.0.0-recommended versions. The release is fully backward compatible on the wire: the three new regulators, the new format and the new read routes are additive, and existing requests are answered exactly as before. The one behavioral change, the 403 on the three audit-chain verification routes for callers without compliance read authority, applies regardless of which client is used.