Why does every new hire ask the same questions even when you have the docs?

Every Friday at the same Series B startup, the same thing happens.

A new senior engineer, three weeks in, joins a code review and asks: "Why are we using Temporal here? Couldn't we just use a queue?"

An older engineer answers patiently. The Temporal decision was made in 2024. There was a queue first. It fell over during a six-hour incident. The team evaluated three replacements. Temporal won on a specific axis — long-running workflows with state — that the queue couldn't replicate.

Two weeks later, a different new hire asks the same question. The same answer is given. Six months in, the third hire asks. By then the original engineer has left.

The wiki has the Temporal RFC. It has the incident report. It has the migration retro. None of it answers the question that keeps getting asked.

Why do docs lose context faster than they're written?

The Mythical Man-Month (Brooks, 1975) named this fifty years ago: a software project's hardest knowledge is the knowledge of why. Why this design and not the alternative. Why this constraint mattered then. Why we accepted this trade-off.

Documents capture decisions. They rarely capture provenance — the constraint set that produced the decision. Worse, embedding-based retrieval makes this problem dramatically worse, not better.

When a document is chunked and embedded, the resulting vector captures the semantic content of the text. What it strips out:

• Who decided this
• What alternatives were rejected
• What constraints existed at the time (and may no longer)
• What other decisions this depends on
• Whether this was a confident choice or a "we'll revisit it" choice

That stripped-out information is what new hires are actually asking for. RAG retrieves the chunk. The chunk doesn't have it.

What are the three knowledge types organizations actually need?

Factual knowledge. "What does this policy say?" "What's the current value of X?" Lives in documents, served by retrieval. This is the easy one.

Relational knowledge. "Who owns this service?" "What depends on the deprecated API?" Lives in connections between entities. Lives badly in chunked text. Lives well in a knowledge graph.

Causal knowledge. "Why did we decide this?" "What chain of events led here?" Lives in the relationships between decisions, the constraints behind them, and the sequence over time. This is what new hires keep asking about, and it's the type embedding-based systems handle worst.

The trap is treating all three as the same problem. You don't fix causal-knowledge gaps by adding more documents. You fix them by capturing the structured context — alternatives considered, constraints, dependencies — alongside the decision.

How do successful organizations handle this?

The companies that hold institutional memory well have one thing in common: they treat decisions as first-class, structured artifacts.

Stripe's internal memos read like the essays the company publishes through Stripe Press — heavy on the "why," explicit about alternatives. Linear's RFC template has dedicated sections for "what we're not going to do" and "context that may change." Amazon's Werner Vogels-era six-pager tradition forces every proposal to be defensible in narrative form, with the constraints surfaced.

None of these are AI-driven. They're cultural. But they produce documents that an AI system can actually retrieve usefully — because the provenance is in the document, not lost in the chunking.

The teams that don't do this end up with three engineers acting as living institutional memory. When one of them leaves, the org loses years of context overnight.

Where does AI fit?

An AI agent can synthesize institutional knowledge — but only if the underlying data captures provenance. Two complementary moves:

1. Restructure ingestion. When a decision artifact is created (RFC, migration plan, incident report), capture provenance fields explicitly: decided-by, decided-when, alternatives-considered, constraints, supersedes, related-decisions. Treat these as required fields, not optional metadata.
2. Build a synthesis layer. An agent that queries across these structured fields, traces decision chains, and reconstructs the "why" — not by summarizing chunks, but by walking the graph.

That's the move the Synthesizing Institutional Knowledge skill is built for — a Claude Code skill that defines the schema, the ingestion shape, and the synthesis routes for organizational memory systems that go beyond document embeddings.

The new hire on Friday is going to ask the same question again next month. The right answer is to build a system that can answer it without needing the engineer who was in the room.