Micro-Disclosure Evidence: Proving What the App Actually Showed, Screen by Screen

A financial app's disclosures live in versions: the fee screen redesigned in March, the consent copy A/B-tested in May, the arbitration flow updated quietly in a patch — so the exam question "did this customer receive the required disclosure" resolves to which variant rendered, for whom, when, and the industry's older answer (a static PDF in a policy binder) stopped answering it years ago. Micro-disclosure evidence is the discipline of making the app's disclosure surfaces provable after the fact: versioned, timestamped, bound to customer sessions, and retrievable by customer and date — the same evidentiary upgrade that consent receipts brought to authorization and session logs brought to onboarding.

3G Times publishes information, not legal advice. Evidence architecture is product-specific; retention schedules and privilege questions belong with counsel.

What needs to be captured?

Four artifact classes cover the disclosure estate. Screen-state records: for each regulated surface — fee disclosures, consent flows, terms acceptance, error-rights notices, arbitration presentations — a versioned capture of what the screen rendered, ideally as structured data (screen ID, variant, content hash) rather than screenshots alone, though dated screenshots remain the fallback courts respect. Exposure events: the binding of screen-version to customer session — customer X saw variant B of screen 14 on this date, with this device and app version, which closes the loop the version-governance program opens. Interaction evidence: the affirmative acts — scrolls-to-end, checkbox toggles, signature moments — that evidence attention and comprehension design where the law demands it (the E-SIGN ceremony being the canonical case). Experiment context: the A/B flags active at the session, because the regulator's follow-up question after "variant B" is always "what differed, and who decided".

Why is this suddenly the exam's favorite question?

Because the supervision caught up with the medium. Digital-disclosure findings now turn on prominence and delivery at the individual level: the customer who complains they were never told the fee lands in a data request where the institution produces — or fails to produce — the rendered screen for that customer's session. The E-SIGN consent dispute ("I never agreed to electronic statements") resolves on the demonstration and consent artifacts the statute always contemplated; the UDAAP mismatch claim ("the app said no fees") resolves on the screen-versus-marketing comparison; the arbitration enforceability fight, in both directions, resolves on what the flow actually displayed and required. In each, the institution with the evidence file answers in one document; the institution without it answers with the best reconstruction available — which juries price accordingly.

The storage arithmetic seals the design choice: exposure events are kilobytes per session, screenshots are megabytes, and the reconstruction service renders from versioned artifacts only when a dispute or audit asks — the ledger scales with customers while the evidence stays pixel-faithful, which is the rare control that is simultaneously cheaper and stronger.

How is the capture built without breaking the product?

As metadata, not screenshots-by-default: every regulated screen carries a version identifier and a content hash at build time; the session pipeline logs exposure events (customer, screen version, timestamp, session context) into the record store governed by the retention schedule; interaction moments append their structured evidence. Screenshots render on demand — a service that reconstructs the rendered screen from version and build artifacts — because storing full captures for every session is storage theater when hashes bind content. The experiment platform contributes its flag assignments to the same session record, making the A/B context queryable rather than discoverable. The result is a disclosure ledger: query by customer and date, produce the screens, the variants, and the flags — one API between the compliance team and the truth.

How does this connect to the adjacent programs?

It is the presentation layer of artifacts the institution already governs. The consent-receipt program records the authorization decision; the disclosure ledger evidences the screens the decision was made on. The E-SIGN ceremony's retained artifacts are exposure events with statutory names. The dark-pattern journey audit walks the same screens the ledger versions — and the A/B governance that reviews experiments for comprehension risk feeds the flags the ledger records. One architecture, five consumers: exams, disputes, arbitration, product analytics, and the next disclosure redesign, which inherits the evidence of the last one.

What does this mean in practice?

• Version every regulated screen at build time — content hash plus identifier, so exposure events bind to something immutable.
• Log exposure, not vibes: customer-session-screen-version-timestamp into the record store, retention matched to the relationship plus tail.
• Make experiment flags part of the session record — the test context belongs in the ledger before it belongs in discovery.
• Rehearse the production: the quarterly exercise that pulls ten customers' disclosure histories end-to-end finds the gaps while they are cheap.

The app era's disclosure law is empirical: what shipped, who saw it, what they did. The institutions that instrumented those three facts treat disclosure disputes as retrievals; the ones that didn't treat them as archaeology — and archaeology, in litigation, is priced like uncertainty, which is to say expensively.

The synthesis across the evidence programs: consent receipts evidence decisions, session logs evidence identity, the disclosure ledger evidence presentations — three artifacts, one query interface, and the dispute that once took a discovery motion now takes an API call. That is the destination: compliance evidence as infrastructure, producible on demand, defensible by construction, and boring — which is the highest compliment operational risk can pay.

Does the ledger serve arbitration fights?

Directly — enforceability disputes turn on conspicuousness and assent, and the ledger's exposure-plus-interaction records are the modern answer to "I never saw it": the screen version, the scroll depth, the affirmative act, bound to the session. The same query that serves the exam serves the motion to compel.

Frequently asked questions

A closing note on the artifacts' half-life: disclosure redesigns, A/B archives, and build artifacts all decay on storage and tooling cycles, so the ledger's reconstruction path needs a periodic test — rebuild three random screens from a year ago, prove the hashes still resolve. The evidence that cannot be rendered when asked is the evidence that was never really kept.

Do screenshots of every screen need to be stored?

No — hashes and structured exposure events bind the content; rendered reconstructions generate on demand from versioned artifacts. Screenshots remain useful for audits and key ceremonies, but capture-everything is storage cost without evidentiary gain.

How long should exposure records be kept?

Match the underlying duty's horizon: the relationship plus the retention tail for the disclosures involved — the same schedule the consent-receipt and CDD records follow, because the same disputes request all three together.

What about A/B tests — are they evidence against the company?

They are evidence of engineering, and governance makes that good: reviewed experiments with comprehension-safety checks and recorded rationale read as a controlled program; unreviewed test logs read as improvisation with metrics. The ledger records what shipped; the review file explains why it shipped — keep both.