Regulatory mapping#
How BitExact's evidence properties map to the record-keeping, oversight, and integrity obligations these regimes impose or are converging toward.
This maps properties to requirements. It is not legal advice, and it does not assert that using BitExact makes a deployer compliant with any regime. The Limit column states where each mapping stops; the boundary in the final section applies to every row.
The properties being mapped#
- Ordered, hash-chained trajectory — every model call through the proxy or a wrapped client (prompt and response), every call to a recorded tool, and captured nondeterminism, in sequence, with a run-open environment fingerprint and a terminal seal.
- Tamper-evidence —
aer-jcscanonical hashing (RFC 8785 restricted to values that canonicalize identically everywhere) and per-field salted commitments; any alteration breaks the chain at the exact step. - Independent verification — a standalone offline verifier (Apache-2.0) re-derives every hash and signature with no vendor trust.
- External anchoring — RFC 3161 timestamps and WORM / object-lock export of signed heads, so rollback by the party holding the store is detectable.
- Honest redaction — remove a value where it lives, keep a signed audit entry and a standing commitment; a false redaction claim fails.
- Reconstruction and interrogation — deterministic replay, and a marked-synthetic counterfactual fork that can never be laundered into the production record.
- Identity, policy, and oversight — asserted principal, the party acted
for and the authority to act for it, whether a person was in the session,
agent, delegation, policy/model versions, retrieval context (hash-first), and
human approve/reject/edit decisions, each committed into the chain and
marked
assertedso it is never confused with observed capture.
EU AI Act (Regulation 2024/1689, as amended by Regulation (EU) 2026/1744)#
Timeline, checked 2026-08-30. The AI Omnibus, Regulation (EU) 2026/1744, was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. It defers the high-risk obligations below: stand-alone Annex III systems (which include creditworthiness assessment) move from 2 August 2026 to 2 December 2027, and AI embedded in products already regulated under Annex I moves to 2 August 2028. The Article 50 transparency duties and the Article 4 AI-literacy duty were not moved. The obligations themselves were not withdrawn, and the mapping below is unchanged. Only the date they begin to apply moved.
| Requirement (functional) | BitExact property | Limit |
|---|---|---|
| Art. 12 — automatic recording of events over the system's lifetime, enabling traceability | The hash-chained trajectory is the record; the verifier and anchors make it tamper-evident and un-rewindable | Records what routes through the proxy or SDK; an out-of-band call is not in the log. An execution BitExact refused to record - a lapsed license, a missing or unlicensed recorder key, a faulty signer or store - still runs, and its refusal is a hash-chained event, signed with the recorder key when one loads and entered in the transparency log. Capture coverage counts it as an execution without evidence, workflow and selection evidence packs carry it, and the open-source verifier checks it; the refusal says that the execution went unrecorded and why, not what it did |
| Art. 14 — human oversight, with the ability to intervene and override | record_human_decision commits approvals, rejections, and edits as evidence, optionally bound to the reviewed step | Records the deployer's assertion that oversight occurred and what was decided - never proof of it; it does not implement or enforce the oversight control |
| Art. 19 / Art. 26 — retain automatically generated logs; deployer keeps logs and ensures oversight | Signed, exportable bundles with retention and legal-hold tooling; oversight and identity committed in-chain | Retention lives in the customer's store; BitExact produces and verifies the record, it is not the archive of record unless the export target is |
DORA (Regulation 2022/2554) — ICT risk for financial entities#
| Requirement (functional) | BitExact property | Limit |
|---|---|---|
| Integrity and traceability of ICT operation records | Tamper-evident chain plus external anchoring detects both alteration and rollback by a party with store access | Covers the agent's model/tool trajectory, not the entity's broader ICT estate |
| Records available and reconstructable for review | Offline independent verification and deterministic replay | Reconstructs the captured trajectory, never asserted as the complete set of system events |
US automated-decision regimes (Colorado, California)#
| Requirement (functional) | BitExact property | Limit |
|---|---|---|
| Evidence of how an automated decision about a person was made | Identity binding - the acting principal, the party acted for (on_behalf_of, a pseudonymous id) and the authority to act for it (authority_ref), each change mid run listed with its step - + retrieval context + the model trajectory + any human decision, all in one verifiable run; every run that acted for a party is found by that party's id | The principal, party, authority and scope are asserted by the deployer and committed as evidence; BitExact does not authenticate them |
| Whether a person took part (GDPR Art. 22 and the US opt-out regimes ask whether a decision was solely automated) | interaction_mode records whether a person was in the session; a human_decision entry records a review and its outcome | A person in the session is not human involvement in the decision: only a recorded human decision is evidence of that, and it too is the deployer's assertion |
| Show what would have differed / interrogate the decision | A verifiable counterfactual fork, recorded as an explicitly synthetic branch | A counterfactual is an experiment; it is recorded as synthetic and cannot be presented as what production did |
Model risk management (Federal Reserve / OCC)#
Superseded guidance, checked 2026-08-30. SR 11-7 was replaced on 17 April 2026 by SR 26-2 / OCC Bulletin 2026-13. The revised guidance is principles-based, is stated to be most relevant to banking organizations above $30 billion in total assets, says it "does not set forth enforceable standards or prescriptive requirements," and places generative and agentic AI outside its scope. The properties below describe what BitExact provides for model governance; they are not offered as compliance with current supervisory guidance, and BitExact's subject matter is explicitly outside SR 26-2's scope.
| Requirement (functional) | BitExact property | Limit |
|---|---|---|
| A record of model use and its inputs/outputs for validation and monitoring | Per-run trajectory with model + model-version identity and the exact inputs and outputs captured | Evidence of individual runs; not a substitute for the institution's validation program |
| Detect and evidence changes in model behavior over a corpus | bitexact regress replays a run corpus against changed prompts/code and reports flipped decisions, signed — the first divergence in each run proven, later findings marked conditional | Detects divergence in replayable behavior; behavior outside the captured boundary is invisible |
FINRA (Rules 4511, 3110, 2210)#
FINRA Rule 4511 (General Requirements), Rule 3110 (Supervision) and Rule 2210 (Communications with the Public), with FINRA's guidance on generative AI and AI agents. Each quote below is verbatim from FINRA's rulebook or guidance, retrieved on 2026-10-31. None of these rows says a firm meets FINRA or SEC requirements; each row states evidence and its limit.
| Requirement | BitExact property | Limit |
|---|---|---|
| Rule 4511(a) - "Members shall make and preserve books and records as required under the FINRA rules, the Exchange Act and the applicable Exchange Act rules." | Each run is an ordered, hash-chained, sealed record of the model and tool calls that route through the proxy or SDK, the policy checks run on them, and the human decisions asserted about them | Whether an agent run is a book or record the rules require is the firm's determination. BitExact records what routes through capture, never the firm's complete books and records |
| Rule 4511(b) - "Members shall preserve for a period of at least six years those FINRA books and records for which there is no specified period under the FINRA rules or applicable Exchange Act rules." | A committed retention_deadline (record_decision) is a deletion floor that purge --delete honors. For a run that committed none, a default duration its workflow declares (workflow set-retention) holds purge --delete until the run's last entry plus that duration, and purge names that floor as the reason it held the run. bitexact workflow show prints the declared default, and bitexact retention lists the runs that carry no committed deadline | Six years applies only where no other period is specified: communications are kept three years under SEA Rule 17a-4(b). The deadline and the schedule are the deployer's assertions. Archiving is allowed under either floor, and the archive is the customer's storage |
| Rule 4511(c) - "All books and records required to be made pursuant to the FINRA rules shall be preserved in a format and media that complies with SEA Rule 17a-4." | See the SEC Rule 17a-4 paragraph (f) rows below | BitExact is not itself a 17a-4 electronic recordkeeping system unless the deployment, including the archive target, meets paragraph (f) |
| Rule 3110(a) - "Each member shall establish and maintain a system to supervise the activities of each associated person that is reasonably designed to achieve compliance with applicable securities laws and regulations, and with applicable FINRA rules." (a)(1) - "The establishment and maintenance of written procedures as required by this Rule." (b)(1) - "Each member shall establish, maintain, and enforce written procedures to supervise the types of business in which it engages and the activities of its associated persons that are reasonably designed to achieve compliance with applicable securities laws and regulations, and with applicable FINRA rules." | Evidence a supervisory system can use: the identity each run acts under, and its delegation; a policy_check for each guardrail's verdict, observed (@bitexact.record_check) or asserted (record_policy_check), naming the step it judged; the promotions on the workflow's governance ledger, each with the principal who recorded it; and investigation cases with their findings | BitExact is not a supervisory system: it does not establish, enforce or test written supervisory procedures. It records a policy engine's verdict and never decides one |
| Rule 3110(b)(2) - "The supervisory procedures required by this paragraph (b) shall include procedures for the review by a registered principal, evidenced in writing, of all transactions relating to the investment banking or securities business of the member." | A human_decision (actor, decision, reason, binds_step) chained beside the step it reviewed | Asserted by the deployer. BitExact does not verify that the actor is a registered principal or that the review was adequate |
| Rule 3110(b)(4) - "The supervisory procedures required by this paragraph (b) shall include procedures for the review of incoming and outgoing written (including electronic) correspondence and internal communications relating to the member's investment banking or securities business. The supervisory procedures must be appropriate for the member's business, size, structure, and customers. The supervisory procedures must require the member's review of: (A) incoming and outgoing written (including electronic) correspondence to properly identify and handle in accordance with firm procedures, customer complaints, instructions, funds and securities, and communications that are of a subject matter that require review under FINRA rules and federal securities laws. (B) internal communications to properly identify those communications that are of a subject matter that require review under FINRA rules and federal securities laws. Reviews of correspondence and internal communications must be conducted by a registered principal and must be evidenced in writing, either electronically or on paper." | The agent's drafted output is captured as the model entry or the http_call / tool_call response that carried it, and the review is a human_decision bound to that step. Python binds it with record_human_decision(actor, decision, reason=..., binds_step=...). TypeScript, Go and Java bind it with their typed helpers, held to the same rule: recordHumanDecision(actor, decision, { reason, bindsStep }), bitexact.RecordHumanDecision(ctx, actor, decision, bitexact.HumanDecision{...}) and Bitexact.recordHumanDecision(actor, decision, reason, bindsStep) | As Rule 3110(b)(2). BitExact captures the agent's calls, not the firm's communications archive: a sent communication is evidenced only if the send went through a recorded tool call |
| Rule 3110, Supplementary Material .07 - "The evidence of review required in Rule 3110(b)(4) must be chronicled either electronically or on paper and must clearly identify the reviewer, the internal communication or correspondence that was reviewed, the date of review, and the actions taken by the member as a result of any significant regulatory issues identified during the review. Merely opening a communication is not sufficient review." | The human_decision is the chronicle: its actor names the reviewer, binds_step names the step reviewed, its entry carries the time, and its decision and reason say what was done | Asserted by the deployer, as above. The custody chain records who exported, forked, held or redacted a run: that is access, never review, and no row here presents it as review |
| Rule 3110, Supplementary Material .08 - "In the course of the supervision and review of correspondence and internal communications required by Rule 3110(b)(4), a supervisor/principal may delegate certain functions to persons who need not be registered. However, the supervisor/principal remains ultimately responsible for the performance of all necessary supervisory reviews, irrespective of whether he or she delegates functions related to the review." | The run's identity entry commits the delegation (delegation_from), the party the agent acts for (on_behalf_of) and the authority to act for it (authority_ref), each change mid run a new chained step; the actor on each human_decision names who reviewed | Asserted by the deployer; BitExact does not authenticate them. Whether a delegation was lawful, and the principal's remaining responsibility for the review, are the firm's |
| Rule 3110, Supplementary Material .09 - "Each member shall retain the internal communications and correspondence of associated persons relating to the member's investment banking or securities business for the period of time and accessibility specified in SEA Rule 17a-4(b). The names of the persons who prepared outgoing correspondence and who reviewed the correspondence shall be ascertainable from the retained records, and the retained records shall be readily available to FINRA, upon request." | The retention floors and the archive (Rule 4511(b) above); the actor on a human_decision names the reviewer | The three-year period of SEA Rule 17a-4(b) is not defaulted: the deployer commits a retention_deadline per run or declares a default per workflow. Who prepared a communication is evidenced only as far as the run's asserted identity names it |
| Rule 3110(b)(5) - "The supervisory procedures required by this paragraph (b) shall include procedures to capture, acknowledge, and respond to all written (including electronic) customer complaints." | Not provided | Customer complaints are outside capture scope |
| Rule 2210(b)(1)(A) - "An appropriately qualified registered principal of the member must approve each retail communication before the earlier of its use or filing with FINRA's Advertising Regulation Department" (b)(4)(A) - "Members must maintain all retail communications and institutional communications for the retention period required by SEA Rule 17a-4(b) and in a format and media that comply with SEA Rule 17a-4. The records must include:" "(ii) the name of any registered principal who approved the communication and the date that approval was given;" | A human_decision bound to the drafting step names the approver (its actor) and carries the time it was made. A decision record (record_decision) whose output_flags set is_communication marks the run's output as a communication and turns on the workpaper's communication criterion | Asserted by the deployer, as is the is_communication flag; BitExact does not verify that the approver is a registered principal. BitExact cannot prove the approved text is the text used unless the send is a recorded tool call: then the reviewed step's output and the send's arguments are both in the chain, for the examiner to compare. Whether an output is correspondence or a retail communication is the firm's classification |
| FINRA Regulatory Notice 24-09; 2026 FINRA Annual Regulatory Oversight Report, GenAI section - FINRA's rules "continue to apply when member firms use Gen AI or similar technologies in the course of their businesses". The report names the risk of "AI agents acting autonomously without human validation and approval", and lists among the practices firms may consider "how to track agent actions and decisions", "human in the loop", "how to establish guardrails or control mechanisms to limit or restrict agent behaviors, actions or decisions" and "storing prompt and output logs for accountability and troubleshooting" | Capture of the model and tool calls that route through the proxy or SDK, with their prompts and responses; interaction_mode (interactive or autonomous) on the run's identity says whether a person was in the session; a human_decision for each validation or approval; a policy_check for each guardrail's verdict | Guidance, not a rule. A person in the session is not a validation or an approval: only a human_decision is evidence of one, and it, like interaction_mode, is the deployer's assertion |
| FINRA Frequently Asked Questions About Advertising Regulation, Questions B.4 and D.8; 2025 FINRA Annual Regulatory Oversight Report, Communications With the Public - "Firms are responsible for their communications, regardless of whether they are generated by a human or AI technology." Of chatbot communications used with investors, "the firm must supervise the chatbot communications in accordance with applicable FINRA rules". The report lists "ensuring the appropriate supervision of those communications, and retention of those chat sessions, in accordance with SEC and FINRA rules." | Each turn of a chat session that routes through the proxy or SDK is captured, prompt and response, as the model entry or the http_call / tool_call response that carried it; a decision record whose output_flags set is_communication marks the output as a communication; a human_decision bound to the drafting step is the review; the retention floors of Rule 4511(b) above keep the run | Guidance, not a rule. BitExact records the communication and the review; it does not judge whether the content meets the standards of Rule 2210(d), and whether the output is correspondence, a retail or an institutional communication is the firm's classification. A chat turn that does not route through capture is not retained |
SEC Rule 17a-4#
17 CFR 240.17a-4, as amended by Exchange Act Release No. 96034 (87 FR 66412). Each quote below is verbatim from the rule text. None of these rows says a firm meets SEC or FINRA requirements; each row states evidence and its limit. BitExact is not itself a 17a-4 electronic recordkeeping system unless the deployment, including the archive target, meets paragraph (f).
| Requirement | BitExact property | Limit |
|---|---|---|
| (b)(4) - "Originals of all communications received and copies of all communications sent (and any approvals thereof) by the member, broker or dealer (including inter-office memoranda and communications) relating to its business as such, including all communications which are subject to rules of a self-regulatory organization of which the member, broker or dealer is a member regarding communications with the public." | The agent's drafted output and what it received are captured as the model entry or the http_call / tool_call response that carried them; an approval is a human_decision (actor, decision, reason, binds_step) chained beside the step it reviewed | The approval is asserted by the deployer; BitExact does not verify who the reviewer is or that the review was adequate. BitExact captures the agent's calls, not the firm's communications archive: a sent communication is evidenced only if the send went through a recorded tool call. The three-year period of paragraph (b) is not defaulted; the deployer commits a retention_deadline per run |
| (f)(2)(i)(A)(1)-(3) - "Preserve a record for the duration of its applicable retention period in a manner that maintains a complete time-stamped audit trail that includes:" "All modifications to and deletions of the record or any part thereof;" "The date and time of actions that create, modify, or delete the record;" "If applicable, the identity of the individual creating, modifying, or deleting the record; and" | The chain is append-only. Redaction, repair, legal hold and release are chained audit entries carrying by and the time. purge leaves a signed purge record naming who, when, the disposition, the steps and the head hash. The custody chain records each export and access. Anchors and the transparency log detect rollback | The identity on these acts is the operator's asserted name, not an authentication of it |
| (f)(2)(i)(A)(4) - "Any other information needed to maintain an audit trail of the record in a way that maintains security, signatures, and data to ensure the authenticity and reliability of the record and will permit re-creation of the original record if it is modified or deleted; or" | Every hash and signature re-derives in the offline verifier. The archive disposition keeps the verified bundle in the customer's immutable storage, read back and verified before the hot rows are dropped | Redaction and purge --delete defeat re-creation by design: the original value is gone from BitExact afterwards. The records regime closes this for redaction: under a workflow that declares the SEC 17a-4 audit-trail regime, redact is refused until the run's verified bundle is in the archive, so the original is re-created from the archive, and purge --delete is refused outright. The redaction, a dual-control request for one, and the viewer's offer all ask the same refusal. A governance ledger that cannot be read refuses both, as the regime would. A field the capture policy scrubbed before capture was never written and can never be re-created |
| (f)(2)(i)(B) - "Preserve the records exclusively in a non-rewriteable, non-erasable format;" | The customer's object-lock storage holds archived bundles and the WORM anchors (recorder-signed heads) | BitExact's live store is not WORM, and an anchor holds a signed head, not the run's bytes |
| (f)(2)(ii) - "Verify automatically the completeness and accuracy of the processes for storing and retaining records electronically;" | verify, health, the transparency-log audit, anchor checks, and the archive's read-back verification before rows are dropped | Verifies the integrity of what was stored, never the completeness of capture |
| (f)(2)(iii) - "If applicable, serialize the original and duplicate units of the storage media, and time-date the required period of retention for the information placed on such electronic storage media;" | Step order is serialized in the chain; a committed retention_deadline is a time-dated retention period that purge --delete honors | "If applicable" per the rule. Serializing the storage media is the storage's |
| (f)(2)(iv) - "Have the capacity to readily download and transfer copies of a record and its audit trail (if applicable) in both a human readable format and in a reasonably usable electronic format and to readily download and transfer the information needed to locate the electronic record, as required by the staffs of the Commission, the self-regulatory organizations of which the member, broker, or dealer is a member, or any State securities regulator having jurisdiction over the member, broker, or dealer; and" | export writes the bundle as JSON, DSSE or JSONL (the usable electronic format). The evidence pack carries the workpaper (workpaper.md) and its reading view (view.html), which shows the runs as readable steps in any browser, offline (the human-readable format). The offline verifier checks the bundles with no vendor trust, renders view.html again from them and fails the pack if it differs | view.html is a reading aid and the workpaper is the producer's own statement; neither is a verification result, and the verdict comes from the verifier. Transferring a copy to a regulator is the firm's act |
| (f)(2)(v) - "Include a backup electronic recordkeeping system that meets the other requirements of this paragraph (f) and that retains the records required to be maintained and preserved pursuant to § 240.17a-3 and in accordance with this section in a manner that will serve as a redundant set of records if the original electronic recordkeeping system is temporarily or permanently inaccessible; or" "Have other redundancy capabilities that are designed to ensure access to the records required to be maintained and preserved pursuant to § 240.17a-3 and this section." | Not provided | The store's backup and redundancy are the customer's |
| (f)(3)(v) - "Have at all times filed with the designated examining authority for the member, broker, or dealer the following undertakings with respect to such records signed by either a designated executive officer or designated third party" | Not provided | A self-hosted product is not a designated third party, and the undertaking is the firm's to file |
Scrubbed, hash-only and withheld fields#
Paragraph (b) requires a broker-dealer to "preserve for a period of not
less than three years, the first two years in an easily accessible place"
the "Originals of all communications received and copies of all
communications sent" ((b)(4)), and FINRA Rule 4511(a) and (c) carry that
duty into FINRA's books and records. A field the capture policy
(capture-controls.md) scrubbed, kept hash-only or withheld is not a copy of
what the agent sent or received: BitExact holds no copy of the original
communication, and nobody can re-create it from the evidence. A holder of
the capture key can only test a candidate value against a hash-only field.
Where an agent's calls carry a communication the firm must keep whole, such
a field may not meet that books-and-records duty. The shipped default
scrubs card numbers, IBANs and credentials everywhere, so a broker-dealer
may need a narrower policy: a keep rule for the step kinds and paths that
carry those communications, ahead of the rules that scrub, or
BITEXACT_CAPTURE_POLICY=off, which bitexact health reports as
capture-policy-off (critical when BITEXACT_ENV=prod). Whether a field
is a required record is the firm's determination. Every run records in its
first entry which policy was in force (its digest), or off, and each
entry declares in its capture block what was kept of each field, so the
run itself shows which fields were kept whole.
HIPAA (45 CFR Part 164)#
What the evidence offers a covered entity running AI agents on patient data. These rows describe product behavior against the Security and Privacy Rules; none of them says a deployment is HIPAA compliant. BitExact declares no healthcare records regime: retention and legal hold work as for any workflow, from the deadlines you set.
| Requirement (functional) | BitExact property | Limit |
|---|---|---|
| Audit controls: record and examine activity in systems that use ePHI (164.312(b)) | The hash-chained trajectory records each model call and each recorded tool call, in order, with a terminal seal | Covers the agent's activity that routes through capture, not your clinical systems; a call made entirely out of band is not in the record |
| Integrity: corroborate that records were not altered or destroyed (164.312(c)) | Hash chain, salted commitments and hybrid signatures; the open verifier names the exact step that changed | Proves the integrity of the agent's record, not of the data held in your EHR |
| Minimum necessary: keep identifiers out of the record (164.502(b)) | The capture policy removes a value before anything is written: built-in detectors (card numbers, IBANs, credentials, US Social Security numbers, email addresses) and custom patterns such as a medical record number; every scrub is declared on the chain | Does not change what the agent sends or receives; names, addresses and free text are not detected (scrubbed-upstream records your claim that you cleaned them, unchecked) |
| Confirm a patient's runs without storing the identifier | A hash-only field stores a commitment under a salt derived from the capture key; a holder of the key tests one candidate at a time, each test recorded on the custody chain first | Hash-only is pseudonymous, not de-identified: a code derived from an identifier does not de-identify it (164.514(c)); treat such evidence as PHI |
| Where the data lives | Self-hosted; BitExact makes no outbound connection of its own, and an evidence pack carries only the runs asked for | Your deployment's own controls (access, encryption at rest, backups) remain yours |
The boundary that applies to every row#
BitExact proves the integrity and reconstructability of what was captured, and surfaces capture gaps through the determinism linter and replay-divergence detection. It does not prove the capture is the complete set of calls an agent made: because BitExact wraps the model and tool interfaces rather than rewriting the agent, a call made entirely out of band never enters the record and leaves no gap to detect. None of the mappings above claim that a deployer is thereby compliant, or that BitExact is certified or approved by any regulator. Each states verifiable evidence a regime requires or is converging toward, and the limit of that evidence. None of the FINRA or SEC Rule 17a-4 rows says a firm meets FINRA or SEC requirements; each row states evidence and its limit.