How the coach reasons

§1The problem shape

Generic AI chat fails at organizational politics in three ways. It forgets the field: the coalition that formed in January is gone from March's conversation. It has no method: asked for advice, it gives advice, even when the right first move is to ask what the asker hasn't noticed. And it isn't grounded: the counsel may come from scholarship or from plausible-sounding air, and there is no way to tell.

The Navigator is built against those failures: a durable record of the user's field, a method that asks before it prescribes, and a curated body of knowledge behind every reply.

§2The reasoning stack

Every consult assembles its context fresh from three layers: the method, the knowledge, and the record.

§3The loop, not the answer

The unit of value is a working loop: map, read, move, rehearse, debrief. When the record is thin, the coach interviews before it advises. Its reads separate what the record documents from what it infers and what is unknown. Its recommendations come in order, with the actual language to use. It will play the counterpart in character so a hard conversation is rehearsed before it is real, and it will red-team a plan before reality does.

The model never writes to the record. Profiles, situations, and updates arrive as proposals the user applies with one click, or doesn't. Every debrief sharpens the next read.

§4Knowledge, distilled and selected

Sources enter through an absorb pipeline that runs in the browser: read locally, distilled section by section, each distillation audited against its source for gaps, then stored as a card plus deep sections. The synthesis is stored, never the source.

At consult time the cards always ride along. When the deep material exceeds the context budget, a fast model selects the sections relevant to the question. The selection never shows in the reply; the coach answers in its own voice. Retrieval is deliberately simple for a corpus this size, with a vector-search upgrade path left open.

§5Isolation and trust

Accounts

Neon Auth (managed Better Auth). Sessions live in a secure, HttpOnly cookie; the client mints short-lived tokens from the session for its own API calls.

Verification

Every API request's token is checked against the auth server's published keys (JWKS). The user id comes from the verified sub claim, never from the client.

Isolation

Every row carries its owner and every query is owner-scoped. No cross-user read path, no admin view into a user's record.

Observability

A health endpoint reports the deployed commit, configuration, a live database ping, and a live auth probe. What is running is inspectable.

§6The stack, plainly

Frontend

Static pages and a single-file application. Zero runtime dependencies.

Backend

Five serverless edge functions. One dependency (jose, for token verification).

Data

Neon Postgres: records, knowledge, consult history, and the auth schema, with branch-per-environment isolation for safe testing.

Models

Claude: the strongest tier for counsel, a mid tier for distillation, a fast tier for relevance selection. Prompt caching holds the stable layers.

The system is small on purpose. The claim isn't scale; it's that grounded, methodical, private counsel can be assembled from first principles.