Worked examples of Sandra doing something useful.
Status: expanded as features land. The shapes below are settled; the exact tool names appear from Phase 1.
The most common setup: one Sandra instance, one team, several projects.
What to record. Five types cover most of it:
| Type | For |
|---|---|
decision |
choices made, with the reasoning |
contract |
agreements between systems or teams |
convention |
rules the code does not enforce |
gotcha |
the thing that cost someone an afternoon |
open_question |
unresolved, so it gets resolved rather than rediscovered |
How it fills up. Nobody sits down to write it. Your assistant records things as they come up in normal conversation, because your project's instructions tell it to.
What you get back. New joiners ask questions and get answers with reasoning attached. Decisions stop getting silently reversed six months later. The person who knew why gets to go on holiday.
Two repositories — a backend and a mobile app — with one Sandra instance between them. This is where a graph earns its keep, because the interesting problems live between the repositories.
Add one verb: impacts, pointing at a module.
Payment endpoint rewrite impacts mobile-app
Payment endpoint rewrite belongs_to_module backend
Session token contract provided_by backend
Session token contract consumed_by mobile-app
Now, working in the backend, your assistant can see what a change will land on the mobile side — and the mobile developer can see what the backend has already decided, without either reading the other's repository.
That question is unanswerable in a per-repository notes file, because the answer lives in the gap between them.
Point a new joiner's assistant at the team instance. Instead of asking colleagues why things are the way they are, they ask their assistant, and get the decision and its reasoning.
The failure mode this replaces is familiar: the reasoning was in a thread, the thread is gone, and the only person who remembers is on holiday.
Record supersedes when a decision replaces an earlier one.
Use a dedicated endpoint supersedes Extend the shared endpoint
You now have a decision history you can walk backwards. When someone asks "didn't we try that?", the answer is available with the reason it was abandoned — which is usually the part that matters.
One Sandra instance can hold several independent memories — one per client, or one per project — that cannot see each other.
Either run a container per project with its own database, or run one instance holding several graphs. Both work; the choice is about how you prefer to operate them, not about what Sandra can do.
Next: Questions.