What the evidence answers, and where it stops.

Every model call (request and response, byte-level, streaming included), tool call, and captured nondeterminism that routes through the proxy or a wrapped client lands in a hash-chained manifest as the run executes; a call made entirely out of band is not in the record. In Python code, the determinism linter flags the usual causes - a direct HTTP call, a model client that is not wrapped - before they ship.

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 record says that an execution went unrecorded and why; it holds nothing of what the execution did.

Entries are ordered, timestamped, and content-committed. SDK runs open with an environment fingerprint and close with a terminal seal, so a completed run is distinguishable from a truncated one; proxy-recorded runs are the raw call chain, where the cross-checked head record and signed checkpoints detect tail truncation. The public verifier enforces the seal rules, so this distinction holds in an independently checked bundle.

BLAKE2b-256 hash chain (SHA-256 in FIPS mode) over salted data commitments detects any in-place alteration; head records are cross-checked on every read and, when a recorder key is configured, hybrid Ed25519 + ML-DSA signed, hash-linked checkpoints attest the chain head during recording. Anti-rollback is anchored by exported signed bundles held by the relying party: the signature pins the head and the complete checkpoint set.

Signed evidence bundles verified independently by the Apache-2.0 verifier on an air-gapped machine, with no BitExact software or license required by the authority. Retention lives in the customer's store; BitExact produces and verifies the record, and it is not the archive of record unless the export target is.

record_human_decision commits approvals, rejections, and edits as evidence, optionally bound to the reviewed step. It 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.

Per-entry redaction removes payload and salt while the chain and signature still verify: the record proves content existed and was committed to, without revealing it.

Bit-exact replay re-executes the recorded run offline; divergence from the record halts with the exact step and a diff. Counterfactual fork answers "what would have happened if…", recorded as an explicitly synthetic branch that can never be presented as what production did.

Per-run trajectory with model and model-version identity and the exact inputs and outputs captured. Evidence of individual runs; not a substitute for the institution's validation program.

The determinism-qualification harness measures byte-exact output stability over N identical requests and emits a self-hashed, optionally signed report.

bitexact regress replays the recorded run corpus against changed prompts or code offline and reports flipped decisions, signed: the first divergence in each run proven, later findings marked conditional. It detects divergence in replayable behavior; behavior outside the captured boundary is invisible.

Evidence bundles carry provider correlation IDs (x-request-id), rate-limit context, retry sequences, and upstream failures as first-class recorded events.

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 agent's model and tool calls, its policy checks and its asserted reviews. Whether an agent run is a required book or record is the firm's determination; BitExact records what routes through capture, never the firm's complete books.

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 is a deletion floor that purge --delete honors; for a run that committed none, the default its workflow declares (workflow set-retention) is the floor, which purge names when it holds the run and bitexact workflow show prints, and bitexact retention lists runs without a deadline. Six years is only the default (communications are three years under 17a-4(b)), the deadline is the deployer's assertion, and archiving is allowed under the floor, into the customer's storage.

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 17a-4(f) rows. BitExact is not itself a 17a-4 recordkeeping system unless the deployment, including the archive target, meets paragraph (f).

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.

Evidence a supervisory system can use: identity and delegation per run, each guardrail's policy_check verdict, approvals and promotions on the workflow ledger, and investigation cases with findings. BitExact is not a supervisory system: it records any policy engine's verdict and never establishes, enforces or tests the procedures.

Reviews of correspondence and internal communications must be conducted by a registered principal and must be evidenced in writing, either electronically or on paper. Merely opening a communication is not sufficient review.

A human_decision (actor, decision, reason, the step it binds) is chained beside the step reviewed, and is the chronicle of the review. It is asserted by the deployer: BitExact does not establish that the reviewer is a registered principal or that the review was adequate. The custody chain records who opened a run; opening a run is access, not review.

the supervisor/principal remains ultimately responsible for the performance of all necessary supervisory reviews

The delegation in the run's identity and the actor on each human_decision, both asserted; whether the delegation is lawful is the firm's.

The names of the persons who prepared outgoing correspondence and who reviewed the correspondence shall be ascertainable from the retained records

The retention floor and archive above. The three-year period of 17a-4(b) is not defaulted: the deployer commits it per run or declares it per workflow.

procedures to capture, acknowledge, and respond to all written (including electronic) customer complaints.

Customer complaints are outside capture.

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 the name of any registered principal who approved the communication and the date that approval was given

A human_decision with actor and time bound to the drafting step; a decision record whose output_flags set is_communication marks the output as a communication, as the deployer asserts, and turns on the workpaper's communication criterion. BitExact proves the approved text is the text sent only where the send is a recorded tool call, and the correspondence or retail classification is the firm's.

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 the practice of how to track agent actions and decisions.

Capture of the model and tool calls that route through the proxy or SDK, with their prompts and responses; interaction_mode 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 an approval, and both are the deployer's assertions.

Firms are responsible for their communications, regardless of whether they are generated by a human or AI technology. the firm must supervise the chatbot communications in accordance with applicable FINRA rules ensuring the appropriate supervision of those communications, and retention of those chat sessions, in accordance with SEC and FINRA rules.

Each chat turn that routes through capture is recorded, prompt and response; is_communication marks the output as a communication; a bound human_decision is the review; the retention floors above keep the run. Guidance, not a rule: BitExact does not judge content against Rule 2210(d), the classification is the firm's, and a chat turn outside capture is not retained.

The agent's drafted output and what it received are captured as the model entry or the tool response that carried them; an approval is a chained human_decision. 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 chain is append-only. Redaction, repair, legal hold and release are chained audit entries carrying who and when; a purge leaves a signed record naming who, when and the disposition; 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.

The archive keeps the verified bundle in the customer's immutable storage. Redaction and purge --delete defeat re-creation by design; under a workflow that declares the SEC 17a-4 audit-trail records regime, redaction waits until the run's verified bundle is archived, and purge --delete is refused. A field the capture policy scrubbed before capture was never written and can never be re-created.

The customer's object-lock storage holds archived bundles and the WORM anchors (recorder-signed heads), and a legal hold blocks purge. BitExact's live store is not WORM, and an anchor holds a signed head, not the run's bytes.

verify, health, the transparency-log audit, anchor checks, and the archive's read-back verification before rows are dropped. These verify the integrity of what was stored, never the completeness of capture.

Step order is serialized in the chain, and a committed retention_deadline is a time-dated retention period. Serializing the storage media is the storage's.

export writes the bundle as JSON, DSSE or JSONL; the evidence pack carries the workpaper and a reading view of the runs that opens offline in any browser; the offline verifier checks the bundles with no vendor trust. The reading view and workpaper are not verification results, and transferring a copy to a regulator is the firm's act.

The store's backup and redundancy are the customer's.

A self-hosted product is not a designated third party, and the undertaking is the firm's to file.

A field the capture policy 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. Every run records in its first entry which policy was in force (its digest), or off, and each entry declares what was kept of each field.

The hash-chained trajectory records each model call (prompt and response) and each call to a recorded tool, in order, with a terminal seal. It covers the agent's activity that routes through capture, not the activity of your clinical systems themselves, and a call made entirely out of band is not in the record.

The same hash chain, salted commitments and hybrid signatures as every other row: any in-place alteration breaks the chain at the exact step, and the open verifier names it. This proves the integrity of the agent's record, not of the data held in your EHR.

The capture policy runs before anything is written, so a value it removes never reaches a spool, the wire, a store, a log line or a backup. Built-in detectors find card numbers, IBANs, credentials, US Social Security numbers and email addresses; a custom detector matches a pattern of your own, such as MRN- followed by seven digits. Every scrub is declared on the chain and counted in the verdict. The policy does not change what the agent sends or receives.

A hash-only field stores a commitment under a salt derived from the capture key. A holder of the capture key can test a candidate value, one at a time, and every test is recorded on the run's custody chain first.

A hash-only field is a keyed hash of its value. Under HIPAA a code derived from an identifier does not de-identify it (45 CFR 164.514(c)). Treat evidence holding hash-only fields as protected health information.

The detectors find only what they are built to find. Names, addresses and other free text are not detected at all: clean them before BitExact sees them, and say so with scrubbed-upstream, which is recorded as your claim, not checked.

BitExact is self-hosted and makes no outbound connection of its own; the evidence never touches our infrastructure. Disclosure is scoped: an evidence pack can carry only the runs of one case, one agent or one period.