Waypoint — career intelligence with provenance

What this is, and what it is not

Waypoint is a private system for keeping track of people, commitments and context over a career. It is not a launched product, a service, or a platform, and this page is not the application — it is the case study. That distinction is stated here as what the work is, once, in its own voice, rather than as a disclaimer under a figure.

The interesting part was never the feature list. It was the question of whether a system that holds something sensitive can be made to prove what it does, to someone who does not trust it and cannot see inside it.

What was hard

A system like this fails in ways that are silent. A record leaks into the wrong account and nothing errors. A correction overwrites the thing it was correcting and the original is gone. A privacy filter stops working and every test still passes, because no test was ever pointed at it. None of these produce a stack trace. All of them are discovered late, by someone else.

So the design problem was not “build the features.” It was: make the guarantees checkable, and make the checks fail loudly when the guarantee stops holding.

What I own

All of it — design, schema, implementation, and the review that would normally be someone else’s job. That last part is the constraint that shaped everything: with no second engineer, the only reviewer available is the machinery, so the machinery had to be built to catch me.

Decision points

Decision 01Enforce ownership in the key, not in the policy layer

The conventional answer is row-level security: a policy on each table that filters by the current user. It works, and it has one failure mode that matters — a policy is a rule applied after the row exists, and a misconfigured or disabled policy layer takes the guarantee with it.

The alternative is to make ownership part of the identity of the row itself, so that a child record can only attach to a parent belonging to the same owner. The database refuses the write because the key does not exist, not because a rule said no.

Choice

both, with the key as the load-bearing one. The check that proves it runs with the policy layer deliberately disabled, so what it demonstrates is that the key holds on its own.

Trade

a schema that is harder to change, because ownership is now in the shape of the data rather than in a rule beside it.

Decision 02Keep what arrived, exactly as it arrived

Every import is a chance to lose something. A parser reads a record, extracts what it understands, and discards the rest — and the part it discarded is precisely the part you need six months later when you are trying to work out why a field says what it says.

Choice

lossless-first. The original is preserved rather than replaced by what was parsed out of it, and captured records are append-only — corrections arrive as additions, and not even their owner can rewrite what was captured. That last clause is enforced by the database and verified against the live system, not merely intended.

Trade

storage, and the simplicity of being able to “just fix” a bad row.

Decision 03Rank on staleness, not on due dates

The system’s daily view was designed to rank what needs attention. The obvious signal is a due date, so I measured what was actually in the data before building it: of fifty-four records carrying a next action, five had a real date and thirty-five said TBD.

A due-date ranking would have surfaced five items and looked broken on the day the real corpus landed. The design ranks on staleness and tie strength instead.

The interface that would render it is specified and not built. That sentence belongs here in the same voice as the rest, because it is what the work is: a design decision grounded in a measurement, which is a different thing from a screen. The pattern is the useful part — observed data, proposed model, evidence invalidating the assumption, design changed.

Verification — the part I would want to be asked about

The hosted database is checked by seventeen numbered assertions that run inside a transaction which always rolls back. Verifying costs nothing and leaves nothing behind, so there is no reason not to run it, which is the only way a check gets run at all.

One of those assertions confirms the cross-tenant refusal with the policy layer bypassed. Another confirms that captured records stay append-only even for their owner.

And the check file itself is part of the trigger set: editing the verification re-runs the pipeline, because a change to the check is a change that has not been verified.

What I got wrong

Six privacy guards protect what a report may contain. To find out whether the tests would actually notice a failure, I broke each of them on purpose.

Five went red. The sixth did not — and it was the one no test covered. It had been working and unverified, which is indistinguishable from broken until the day it matters.

The gap is closed by a regression test written to fail if that guard is removed. The previously invisible failure is now observable.

That sequence is the most useful thing in this case study, and it is the reason the rest of it can be trusted: the guarantees on this page are not claims about intentions, they are claims that were tested by trying to break them. The specifics of which guard, what thresholds it uses, and how the policy layer is disabled are deliberately absent — the technique is the evidence; the topology of a live boundary is not something a case study needs to publish.