SecondLook

01-findings
02-week
03-evidence
04-refusal
05-approval
06-check-dose
07-integrity
08-close

Inspiration

I wanted to build something for Alexa+ that wasn't another "ask the assistant a question" demo. Home medication coordination is a problem I've heard about secondhand more than once — family and friends juggling an elderly relative's care, where a discharge note says one thing, the pharmacy label says another, and someone eventually finds out the hard way that two people gave the same dose because nobody wrote it down where the other person could see it. The part that stuck with me wasn't the mistake itself — it was that afterward, nobody could reconstruct what actually happened. There was no record anyone could point to and say "here's exactly what was given, by whom, and under what authority." That's what I set out to build: not a reminder app, a record that can answer for itself.

What it does

Second Look is an MCP server that sits between an Alexa+-style client and a household's medication record. It answers three questions: is this dose consistent with the plan, is the plan being followed correctly, and what still needs a person to decide. Every answer comes back with the event IDs behind it — nothing is asserted without evidence you can open and read. Recording a dose is never blocked, because carers need to log what already happened, no questions asked. But changing the plan itself requires authority: someone without it gets refused, the refusal is written to the audit log, and it turns into a pending request the right person can approve later. Nothing fails silently and nothing disappears.

How I built it

Built it solo, over about five days: TypeScript on Node 22, Express serving the MCP endpoint over Streamable HTTP on the current spec (2025-11-25), and a React/Vite/Tailwind client that's a real MCP client itself — it doesn't peek at the server's internal state, every rendered answer came back through an actual tool call. The record underneath is an append-only JSONL log, SHA-256 hash-chained so edits are detectable, with six rules folded over it to surface findings like missed doses, conflicting prescriptions, or an unauthorized change. I also wired up an optional operator command that anchors the verified log to Amazon S3 with Object Lock, so there's an external, immutable copy outside anything that could rewrite the local file.

Working alone, I ended up treating the spec docs as my own rubber duck — I wrote a PRD, a decision log, and a security review before letting myself touch the rules engine, mostly so three-days-later me wouldn't have to reconstruct why four-days-ago me made a given call.

Challenges I ran into

No one across the room to ask "does this actually make sense" meant almost every design decision had to survive being written down and re-read a day later, or it got reworked. A couple of specific ones: my first hash-chain verifier was hashing the schema-projected version of each event instead of what JSON.parse actually produced, so an injected field could slip past undetected — took a failed run to catch that. Deciding what a "refusal" should even look like took longer than expected too; my first instinct was to throw an error, but that meant a client that mishandled errors could drop a carer's request with no trace at all. Turning it into a successful, renderable result that also writes an audit event and opens a pending approval took a few passes to land. And writing the honest "what a real Alexa+ deployment still needs" section — OAuth, protected-resource metadata, all of it — meant admitting in my own README how much of this demo isn't production-ready. Easier to leave out, more useful to write down.

Accomplishments that I'm proud of

244 tests and 96.8% line coverage on the parts that matter — rules, fold, log, authority checks — not for a badge, but because I don't have a teammate to catch what I miss. npm run verify-log catches real tampering, not just missing files: I can edit one field in the seeded log by hand and the verifier tells me exactly which event broke the chain. And the refusal-to-pending-approval loop works end to end — you can watch a carer without authority get refused, see it land in the audit log, and watch someone who has authority clear it.

What I learned

Working solo taught me to write things down earlier than feels necessary — the PRD and decision log weren't overhead, they were how I kept arguing productively with myself instead of quietly rewriting code because I'd forgotten my own reasoning from two days earlier. I also learned a lot about the current MCP spec by being forced to get npm run verify-protocol to pass 17 out of 17 against my own running server, instead of just assuming I'd implemented Streamable HTTP correctly.

What's next for Second Look

The README is upfront that this isn't production-ready, and that list is my actual roadmap: OAuth 2.1 with PKCE and the resource parameter, protected-resource and authorization-server metadata, a proper 401 challenge once the platform supports the WWW-Authenticate header, encryption at rest for the local log, and support for more than one person on the same household record — right now identity is closer to "one record, one household" than true multi-person voice profiles. If I keep building this past the hackathon, that's where I pick back up.