AI use and data-loss controls
Alder Creek Community Bank

1. Control mapping

Charter and supervision. Alder Creek Community Bank is an Ohio state-chartered, FDIC-insured nonmember bank. Its federal supervisor is the FDIC and its state supervisor is the Ohio Division of Financial Institutions. Every citation in this package is the rule that reaches an institution of that description.

Each data class, the obligation it answers to, and the rung it currently sits on. Where role groups differ, the strictest rung in force is named and the spread is listed beside it — a ladder climbed one department at a time is a ladder whose cells disagree on purpose.

2. Policy version history

Every version dated, with the weeks it governed, the events decided under it, and what the log shows happened while it was the law. The proposal is carried in the same shape as the versions in force while being visibly not in force: it governs no week and decided no event.

3. Monitoring evidence

1,144 detections across 3,805 AI interactions in the period — 30.1% of AI use carried a sensitive class. Discovery counts every interaction and detection counts the subset; the two denominators are never mixed in one figure.

What happened to them. 34 blocked in the page, 230 redirected to the internal assistant, 38 abandoned after the coach card, 337 submitted after a transform, 75 overridden with a logged justification, and 430 monitored without interruption. A detection is not an exfiltration. Blocked, redirected and abandoned submissions reached no destination; transformed ones reached it with every detected span masked or tokenized and the original text withheld; overridden and monitored ones went as typed.

Detections against class instances. An event can carry several classes, so class instances outnumber detections: 1144 detections in this window carried 1847 class instances, of which 1840 fall in the six classes the tiles draw. A loan application carrying a name, a tax identifier and an account number is one detection and three instances. The two figures are never divided into one another.

4. Sampled provenance chains

6 events, each with the full chain: who acted, what was detected and by which detector, what was decided and under which version, what transform ran, and where the content went. The chain printed here is the chain the console drills to — the same record, not a summary of it.

How these chains were chosen, and what the rest of the log does. Every chain in this section replays: each stored span comes back from the detection engine, from the stored excerpt, at the same offsets with the same proof. That is a selection rule and not a filter on any figure — no count anywhere in this package moves because of it. 650 spans across 650 of the log’s events do not replay in one specific way, and it is a property of one class rather than a defect spread across the log: Customer/Member PII is a combination — a name beside an identifier — and this record holds more member-PII events than identifier detections in the same window, so several hundred names carry no identifier for the rule to pair with. On those events the name is proven at exactly the stored offsets by the engine’s own name rule and the pairing is seeded; the console says so on each such chain, in place. They are counted in every figure in section 3 and none of them is an exhibit here.

5. Detection accuracy

Precision and false-positive rate are computed from the dispositions of the adjudicated sample, never asserted. An unreviewed detection is not evidence of anything, so it is not in the denominator — and the errors are listed rather than netted off, because a report that hid its false positives would be advocacy.

How the sample was drawn. The adjudication queue is a stratified sample of the detections in the trailing thirty days: each data class contributes in proportion to its share of the window, and within a class events are taken in a fixed order derived from the pilot seed. Detections separately reported as errors are included as well. Reported errors are in the sample by construction rather than by the draw, so precision over this sample is a floor on the sample’s own accuracy and not an unbiased estimate of the control’s. Recall is not measured at all — see the accuracy record. Draws alternate between the two adjudicators in the sampled order, so neither officer marks a contiguous block and the sample carries both signatures.

Who marked it. M. Halloran (Compliance officer, first line) marked 60; Y. Abadi (BSA officer, second line) marked 60.

The next draw. 16 detections have been drawn by the same rule and carry no verdict yet. They are not in either figure above, because an unreviewed detection is not evidence of anything.

6. Override and exception record

Override rate is overridden ÷ warned, per week, both read off event fields. It stands at 11% against a 15% target, 11 points below its 22% peak inside this 30-day window — the pilot-wide fall, week 5’s 22% to week 10’s 11%, is the findings strip’s figure and carries its own denominators. Authorized exceptions are a control, not a hole: each carries the group it was granted to and the justification that was logged.

7. Custody of this record

What this artifact holds. Every record behind this package is fictional and generated: one seeded event log for an institution that does not exist, with fictional people, fictional account and loan numbers, and excerpts written by the generator. Nothing here is any real person’s information, and no real institution’s traffic was read to produce it. The excerpts are excerpts by construction — the log stores the fragment a detection was found in, never a full prompt.

What it does not hold. Text a visitor types into the intercept simulator is classified in the request and stored nowhere: there is no database in this deployment, no write path from any surface, and no log line carrying the text. That is why a visitor’s own intercept never appears in this package or in the event log behind it, and why nothing a visitor marks on the adjudication queue survives a reload. The demo will not persist a reader’s words in order to look more capable.

How this copy is reached. Where this build is deployed it sits behind a passcode, and the machine-readable feed sits behind the same gate as the pages — the evidence API is not a second door. The gate keeps fictional figures away from search engines; it is a cookie check and not authentication, and this package says so rather than implying a control it does not have. A checkout run locally with no passcode configured has no gate at all.

What the product intends, which this demo does not evidence. The product definition’s privacy posture is no long-term retention of full prompt content, with the retention window and the access model configurable by the institution (§5.2) — and the demo takes no position on what a bank should choose. That is a statement of intent recorded here because a reader of an examiner package is entitled to ask where the product itself stands; it is not a measurement, nothing on this page evidences it, and the retention schedule, the encryption posture and the access model for a production deployment are open questions this build does not answer.