My new WIMPER Ops dashboard was supposed to be read-only. Independent review found four ways that claim was not yet true enough.
The system had inferred evidence links, mishandled reviewed items marked not applicable, retained stale client identity during account changes, and wrote to the database on the first page load. I fixed each one, then required 230 of 230 requirement checks to reconcile before releasing the five-account portfolio.
What Got Built
- I released WIMPER Ops Evidence Readiness Phase 3A. It gives five accounts a read-only portfolio view of document requirements, proof gaps, and review state. The release passed 230 of 230 requirement reconciliations before production authorization.
- I shipped Phase 3B reconciliation. The process added 11 document-backed review rows across four accounts while preserving the baseline proof gaps, waits, and production record counts.
- I added a query-only release gate. It tests authorization, account switching, allowed web requests, domain reconciliation, and complete database fingerprints before and after the first and repeated reads.
- I created a 1,196-word Medicare guide. Understand My Medicare draft #107 explains why Medicare Advantage benefits can change each year, and the site deployment completed successfully.
- I kept the acquisition system honest. A five-prospect WIMPER referral batch produced zero drafts because Apollo found no verified person-level email for any candidate. The content gate and social listener were also allowed to return zero instead of padding their queues.
What Broke (And How I Fixed It)
The phrase “read-only” sounds simple. Show information, but do not change anything.
In a real application, that promise reaches much farther than the visible buttons. It includes what happens when the first person loads the page, what remains in the browser when they switch accounts, where every displayed link came from, and whether the database changes even when nobody clicks Save.
Independent review found four classes of failure before I released Phase 3A.
First, the candidate inferred Work Board links instead of using the canonical links already established in the earlier phase. An inferred link can look correct and still send someone to the wrong record. That is especially dangerous in an operations tool because a polished interface can make guessed relationships feel official.
The fix was to use the Phase 2B semantics as the source of truth. The dashboard could display only the relationships the system could actually prove.
Second, reviewed requirements marked not applicable did not reconcile cleanly. A document requirement may be reviewed and intentionally excluded, but the dashboard still has to explain that state without treating it as missing proof or completed evidence.
The fix was not better wording. I made the reconciliation deterministic, then required every one of the 230 requirements to land in the correct state before release.
Third, client state could survive an identity change. If an operator used “View As” to switch from one account to another, cached information from the first account could remain in the browser long enough to create a misleading or unsafe view.
The repair cleared client state across identity transitions. I then tested direct identities and switched identities instead of assuming a successful login covered both paths.
Fourth, the first authenticated page request initialized part of the database. SQLite is the small database file behind this system. A page can appear read-only while its startup code quietly creates or changes internal structures.
That made the interface functionally useful, but it violated the release claim. A read cannot be called query-only if the first read changes the database.
I moved the release path to query-only SQLite access and compared complete database fingerprints before and after the first request, repeated requests, and rejected write requests. The gate also checked authorization and verified that a POST request, which is commonly used to submit changes, remained blocked.
Only after those checks passed did Phase 3A receive release authorization.
Phase 3B then applied 11 document-backed review rows across four accounts. It preserved the existing proof gaps and waits rather than rewriting history to make the new view look cleaner. A second application wrote zero rows, which proved the reconciliation was repeatable rather than additive every time it ran.
The referral draft bank failed for a different reason, but the same rule applied.
Apollo returned five plausible matches for ranked Texas commercial insurance agency leaders. None had a verified person-level email. The system created zero prospects, zero drafts, zero sequence reservations, and zero sends.
That is not a productive-looking result. It is a trustworthy one.
The same-day work log was also unavailable when the chronicler ran. This article uses the 77-event primary receipt set, seven calendar-day commits, yesterday’s work log, and current system state. The missing source reduced the claim instead of giving the agent permission to estimate.
The Lesson
Define “read-only” as a testable contract.
Here is what I would tell someone building an operations dashboard: hiding edit buttons is not enough. Test the first page load, repeated loads, identity changes, rejected write methods, and the complete database state before and after each action. If any read changes storage, the feature is not query-only yet.
Make independent rejection produce a permanent gate.
Review is wasted if a finding gets patched once and then lives only in a conversation. Turn each failure into a repeatable check. In this release, inferred links, not-applicable reconciliation, stale account state, and first-read writes each became conditions the next candidate had to pass.
That changes rejection from delay into infrastructure.
Preserve inconvenient baseline facts.
A new reconciliation should not erase missing documents, external waits, or incomplete proof just because the updated dashboard would look better without them. Carry those gaps forward, attach only document-backed review rows, and make a second run prove it has nothing else to add.
A clean interface is useful. A clean interface that hides unresolved work is dangerous.
Let zero output protect the experiment.
Five reasonable names are not five qualified recipients. If verified person-level email is part of the recipient contract, missing email means stop.
The correct fallback is not a generic inbox, a guessed address, or a weaker standard. The correct output is zero drafts and a receipt showing why.
The Numbers
- Commits: 7 total (0 agent, 7 Matt)
- Agent jobs run: 27
- Prospects added: 0
- Emails sent: 0
- Social posts: 3
- Content published: 6
- Event receipts reviewed: 77
- WIMPER requirements reconciled: 230 of 230
- Document-backed review rows added: 11 across 4 accounts
- Rows written on the second Phase 3B application: 0
- Referral candidates checked: 5
- Verified person-level emails found: 0
- Medicare guide drafted: 1,196 words
The most important number is not 230. A large passing count means little if the test ignores hidden writes or stale identity state.
The useful result is the combination: 230 of 230 requirements reconciled, complete database fingerprints unchanged during reads, and zero rows written when Phase 3B ran a second time.
The two zeros in acquisition matter too. Zero verified emails led to zero drafts. The system did not turn weak enrichment into permission to contact someone.
What’s Next
Keep WIMPER Ops in maintenance-only mode, review the 22-item content backlog, and enrich the referral candidates without weakening the verified person-email gate.