In legal review — not indexed
This page describes what Otto does and is readable in full. It stays out of search until it has been reviewed, because a product claim about a compliance control is a claim somebody will hold us to.
One-click audit packages
Otto's audit export turns the running record into a package on demand: a ZIP holding the event log, per-account compliance summaries, a chain-of-custody list with per-file hashes, the rights-invocation log and the call-compliance log, plus a SHA-256 fingerprint of the package itself and an audit entry recording that the export happened.
Key facts
- Six files: a cover memo naming the scope, the audit event log as CSV, per-account compliance summaries, a chain-of-custody list, the rights-invocation log as CSV, and the call-compliance log as CSV.
- The archive is assembled in the browser and hashed with SHA-256 over the actual bytes the recipient receives. The fingerprint is computed, not decorative.
- Scope is a filter over one record, not a rebuild: a single account, one client's placements, or everything.
- A separate printable view produces a cover page, summary counts, a rule-compliance summary, a PII access log with granted and denied reveals, and the full event timeline.
- The export is itself an audited event, written with its scope and its hash.
- The demonstration exports synthetic data and prints that fact at the foot of the printable report.
What is in an Otto audit package?
A cover memo naming the scope, the date and the contents. The audit event log as CSV, one row per event, with timestamp, actor, role, event type, account, client, detail and originating address. Per-account compliance summaries showing queue, hold, verification progress, attached media and attorney reviews. A chain-of-custody list giving each file its hash, the date it was added, the system it came from and the account it belongs to. The rights-invocation log with the type, source, confidence and status of each detection. And the call-compliance log with outcome, consent flag and recording flag per attempt.
How does one click replace weeks of assembly?
By not assembling. The reason an exam sample takes a firm weeks is that one row of the schedule is spread across six systems that were never joined — the case record has statuses, the dialer has recordings, the letter vendor has send dates, imaging has the documents, the trust ledger has payments, and the credit-dispute system has the disputes. The package is fast here because the events were written to one record as the work happened, so the export is a filter and a serialisation rather than a reconstruction. That is a claim about where the data lives, not about how hard anyone works.
What does the SHA-256 fingerprint prove, and what does it not?
It proves the archive has not changed since it was generated: recompute the digest over the file you received and compare. That is genuinely useful for a package that will travel by email and sit on a shared drive for a year. What it does not prove is that the underlying record was never altered before the export — a hash over an export is a seal on the envelope, not on the history. Otto's security page describes the audit trail as append-only and content-hashed as a production property. TODO: verify whether per-event hash chaining is implemented server-side before this page describes the underlying log as tamper-evident, because the shipped demonstration keeps an append-only log in memory and hashes only the exported archive.
Who can generate one?
Three entry points, one mechanism. From the audit screen, over whatever filter is applied — account, client, event type. From an individual account, scoped to that account. And from Glass, where a placing bank requests a package over its own placements and the request lands as work on the firm's side. The scope label travels into the cover memo and into the audit entry, so a package that arrives later can be matched back to the request that produced it.
What about retention?
The cover memo records the retention basis the package was produced under, and the platform's retention model treats compliance records and trust records as separate classes with different clocks. Records evidencing compliance run for a period after the last collection activity and call recordings run from the call, while trust records run considerably longer under state bar rules. TODO: verify both retention periods against the current rule text and the applicable state bar rule before publication, and confirm that configured retention actually disposes on schedule in the deployment being described.
What is built today?
The archive assembly and the digest are real code doing real work in the browser — a ZIP is genuinely produced, the digest is genuinely computed over its bytes, and the download is a real file. The contents are synthetic, and the printable report prints that on the page rather than leaving the reader to infer it. The staged progress messages in the export dialog are presentation.
This page describes Otto, not the law, and is not legal advice. Otto applies rules that have been written down correctly; it does not warrant that using it results in compliance with any statute, regulation or contract. Where a rule is named here, confirm it against the primary source and your own counsel before relying on it.