Sightline samples

Sightline Verdict · Boone Supported Living · fixed-scope diagnostic

Sample verdict document

This is an illustrative deliverable — shortened and with vendor details removed. It shows what a Sightline engagement ends with: not a bug list, but a map of where promises are at risk.

Boone Supported Living — supported living provider (Midwest). Client named with permission; URLs and vendor details removed. Content is representative of a real engagement, not a live client file.

01 — The promise

What the organization believed the system was doing

Residents at Boone Supported Living could submit maintenance requests through the website when something needed fixing at their residence.

The maintenance request form was treated as the primary path for residents to ask for help — not marketing, not family intake, not placement. Staff assumed every submission reached the maintenance team. Leadership believed the digital path matched what residents were told in person and on the phone. For a highly vulnerable audience, some requests were urgent; silent failure was especially harmful.

BDR-0005

02 — Exposure surface

Where promises are at risk

An exposure surface is a map of where the system's promises might fail — sorted by urgency, not by which team owns the fix.

Tier Finding Why it matters
Urgent Maintenance request form failing silently — expired or missing third-party API key Every submission since key failure discarded with no error shown to the resident and no alert to staff — including requests that were sometimes urgent
Watch No error monitoring on form submission path Next failure would repeat the same silent gap — no one would know until a resident escalated or staff noticed a pattern
Watch Success message still displays after failed submission Residents believe help is on the way; staff believe silence means low volume rather than a broken path
Watch No backup visibility for submissions until interim safety net installed Google Sheet sync was added so staff could check requests while the root cause was sorted — but that path was not designed as permanent infrastructure
Stable Phone and in-person reporting still reached staff Human paths worked — but residents who trusted the form had no signal that their request never arrived
BDR-0017

03 — Seams named

Where interpretation authority changed hands

These are the handoffs where meaning got lost — not because anyone failed, but because no one owned the seam.

  • Original developer departed — no one retained backend access or API credentials documentation
  • Web team owned the WordPress form plugin and front-end UX; operations owned maintenance response — neither monitored whether submissions actually arrived
  • Form plugin vendor rotated API keys; renewal notice went to a departed employee's inbox
  • "The site works" tested visually, not functionally — the form looked fine while maintenance requests vanished
  • Mail path from form plugin through WordPress core had no tracing until a custom plugin (Mailscope) was built to follow what happened after submit

04 — Verdict

What you can't un-see

One paragraph. The diagnostic question answered.

The system did not keep the promise it made to residents. They were told they could request maintenance online and expect staff to receive it. For months, the form looked fine while every submission vanished — and because nothing alerted anyone, the organization interpreted silence as low volume rather than a broken path. For a vulnerable audience, that gap is not abstract: urgent requests can look handled when no one on the other end ever saw them. The risk isn't one expired key. It's that no seam between web, the form plugin, and operations was owned enough to catch it.

BDR-0005

05 — Recommended sequence

What to fix first — and what to watch

Not a build proposal. A priority order so fixes don't scatter.

  1. Restore and verify form delivery — rotate or restore API credentials, submit test maintenance requests, confirm staff receipt
  2. Keep the Google Sheet safety net until delivery is verified — interim sync so staff stay current while root cause is fixed; decide later whether a permanent backup path is needed
  3. Fix the success-state lie — form must not thank the resident when submission failed
  4. Deploy mail tracing (Mailscope) — trace the path from form plugin through WordPress core so the next failure is diagnosable, not silent
  5. Add submission monitoring — alert on failure, not on silence
  6. Assign seam ownership — one role accountable for "do maintenance requests still reach staff?" quarterly

Full Sightline engagements include facilitated readout and seam documentation. This sample shows the written artifact only.

BDR-0024 · BDR-0031