Parsed in memory. No client names stored.

Your export is parsed in memory. Attachments are read from bytes, with hard caps on file size, row count and column count. An oversized file is stopped rather than run.

What comes out of it is a set of findings, not a copy of your file. A finding carries the producer and the Marketplace application ID and nothing else. No rows and no field values are copied out of the export.

The audit record holds agent names, application identifiers, findings, timestamps and send history. It carries no client names.

When a client name has to appear on an owner report, it is read from your own ledger at the moment the report is built, and left blank if your ledger no longer carries it.

The record of each file audited is metadata: file name, byte and row counts, field names, and how many values each field held. No rows. No field values.

A snapshot of that record and of your configuration is encrypted with a public key and copied off the machine to write-once storage at every restart.

Beyond those categories the record holds nothing about a consumer: no client name, no date of birth, no Social Security number, no address, and no row copied out of an export.

The record lives on a single machine with full-disk encryption, and the copy that leaves it is encrypted with a public key before it goes.

Contractual terms covering material an agency sends — custody, handling, and the obligations on each side — are set out in the customer agreement, and we walk a compliance reviewer through them on the call.

Each agent receives their worklist as an HTML email. No spreadsheet is attached to an agent's audit report, on any run. The spreadsheet version is written to the administrator's own disk. The only spreadsheet VitalBot ever emails is the management-only breakdown, sent on request to the addresses you authorize — never to a producer.

An agent who leaves the agency keeps the emails they were sent. They never receive an exportable client list from VitalBot.

An audit is triggered by one person emailing one file to one mailbox. That person has to be on the short authorized-sender list your agency maintains.

A regular agent who emails the same export cannot start anything. No audit runs, and the intake is built to tell your authorized list who sent it.

The intake is built to refuse a sender who belongs to a different agency, rather than audit their export against the wrong agency's ledger.

Four independent holds are built to stop a run before anything reaches an agent: a per-agent and agency-wide count limit, a column-drift hold, a missing-date-source hold, and an all-codes volume hold. A held run goes to management with the reason named.

A fifth guard covers one producer at a time. If a producer's book is missing from the export entirely, their findings are held back and sent to the owner, while every other agent's report goes out normally.

Findings your agency marks internal go to management only. Delivery to an agent requires an explicit entry in your configuration. Anything blank, unknown or mistyped is held back and flagged for review.

It does not contact your clients. There is no outbound calling, texting or emailing to a consumer anywhere in the live system.

It does not contact a third-party agent on your behalf.

It does not file anything with a regulator.

It does not recover anything. It reports what it observed in the file you sent, and stops there.

It does not read your enrollment platform, your carrier portal, or any government system. It reads the export you email it and the ledger you point it at.