The Envelope as a Books-and-Records Object

Records rules do not care how elegant a computation was; they care whether the firm kept a retrievable, faithful record of what it told people. The envelope is that record, pre-formed — the retention mechanics stay the firm's.

Two records regimes shape how regulated financial firms think about anything shown to a customer. Broker-dealers preserve communications and records under Securities Exchange Act Rule 17a-4, with its familiar retention periods and its electronic-storage requirements. Investment advisers keep books and records under Advisers Act Rule 204-2, including communications relating to advice. Neither rule was written with computed calculator outputs in mind, and both can reach them when a computed number becomes part of what a firm communicated. This piece is about what the response envelope contributes to that obligation — and, just as carefully, what it does not.

What makes a record format good

A records lawyer's questions about any stored artifact are mundane and merciless: what is it, when was it made, is it complete, has it been altered, can you produce it. The envelope answers them structurally. It is self-describing — model, spec version, inputs, outputs, assumptions, cited constants, disclaimer, all in one object, interpretable years later without the vendor. Its SHA-256 record, computed over the model, spec version, inputs, and outputs under a stated canonical-JSON recipe, means alteration is detectable by recomputation. And it is reproducible: while the spec version is unchanged, re-running the inputs regenerates the identical outputs, and when the version has moved, the public changelog explains the difference. Storage formats rarely arrive with this much built in; here it arrives as the API's default output.

The division of labor, stated plainly

The table's last row is the piece's honest center. Retention periods, retrieval SLAs, indexing, legal holds, and — for broker-dealers — the electronic-recordkeeping requirements of 17a-4, in either their write-once or audit-trail form, are properties of the firm's storage system and its policies. An envelope written to a compliant store can serve as a compliant record; the same envelope in a mutable scratch database cannot, and nothing about its hash changes that. What the hash adds inside a compliant store is a cheap, per-record integrity check the firm can run at any time — a useful supplement to the store's own guarantees, never a replacement for them. Firms should route the storage design through whoever owns their records schedule; the envelope-storage guide (/writing/storing-the-envelope) covers the table shape, and this piece adds only the regulatory frame around it.

Retention design for computed answers

Which envelopes to keep, and for how long, follows the communication they supported rather than the computation itself. A number shown in a customer conversation inherits that conversation's retention class; a number inside a delivered document inherits the document's. The write-at-trust-boundary discipline from the storage guide already aligns with this — envelopes are written when an answer is shown, exported, or acted on — so the records mapping is usually a classification exercise, not new plumbing. Two additions earn their keep in regulated settings: verify each envelope's hash once at write time, so integrity starts at ingestion, and record the verification event, because a dated log of integrity checks is itself the kind of record examiners like to see exist.

• ✓Classify envelopes by the communication they supported — retention follows the conversation or document.
• ✓Store them in the system your records policy already governs, not a side database.
• ✓Verify the hash at write time and log the verification.
• ✓Keep identity in your own keys, outside the envelope — production to an examiner then discloses only the computation.
• ✓Confirm the storage form with records counsel — write-once versus audit-trail is their call, not an API property.

What this buys at examination time

The practical payoff arrives when someone official asks what the firm's tool told a customer on a given date. The firm with envelope records answers with a retrieval and a hash check: this is the record, here is the proof it is unaltered, here are the inputs, the version, the assumptions, and the constants it relied on — and if you wish, here is the recomputation. That is a better morning than reconstructing a number from application logs. None of it happened because a vendor promised compliance; it happened because a well-formed record format met a firm that stored it properly. This piece is an engineering description of that meeting point, not legal advice — the records rules' application to any particular firm belongs to its counsel.