The policies it ships with

People and their agents follow these when they record in a collection made from this template. Its owners can change them.

1. A node belongs in an FAQ when it captures one recurring question and its reusable answer. Each Reference is one entry: its prose is the question and its `answer` is the reply. PASS when the candidate is a question people ask more than once with an answer worth reusing. FAIL only when it is a one-off note, a decision record, a process step, or a passing remark rather than a question with a reusable answer.
2. Only Reference, Log, and Principal belong in an FAQ. Each entry is a Reference — its prose is the question and its `answer` carries the reply; each result of asking is a Log (with an `outcome` of `succeeded` or `failed`); Principals are the stewards who own entries. A process step, decision record, or free-form note belongs in its own collection.
3. Only these edge types may be used in an FAQ: `attributed_to` (an entry → the Principal who stewards it), `supports` (a result Log → the entry that resolved it — usage as evidence), `relates_to` (a see-also link between related questions), `has_parent` (place a narrower question under a broader topic question), `replaces` (a canonical entry supersedes a merged duplicate), and `derived_from` (an entry → the result Log(s) whose gap it was written to fill). An entry cites its source inline in its `locator`, not via an edge.
4. Every committed (`queued` or `active`) FAQ entry carries an `answer` — a question with no reply is not yet an entry. A `drafting` stub may capture the question first and fill in the answer later.
5. Every committed (`queued` or `active`) FAQ entry names the Principal who stewards it — an `attributed_to` edge from the entry to that Principal — so there is a clear owner accountable for keeping the answer fresh. A `drafting` entry may defer naming the steward.
6. Check the FAQ entry's `prose` — the question. PASS when it poses ONE genuine question phrased the way a real user would ask it (e.g. `How do I reset my password?`, `Why was my card declined?`). FAIL when it bundles several questions into one entry, is phrased from the organization's point of view or in internal jargon rather than the user's words, or is a statement or topic label rather than a question.
7. Check the FAQ entry's `answer` together with its `prose` (the question). PASS when the answer leads with the direct response to the question and is concise and self-contained enough to resolve it on its own (a couple of sentences or a short list), leaving deeper or authoritative detail to the linked source. FAIL when the answer buries or never states the actual answer, is a wall of text, is marketing copy rather than a plain reply, or merely re-points to a source without answering.
8. Capture one question per entry, phrased the way people actually ask it. Mine the real wording from support tickets, chats, and search queries rather than inventing an idealized question, and split a compound question into separate entries so each has one clear answer.
9. Lead with the answer and keep it concise and scannable — enough to resolve the question on its own. Keep the authoritative detail in ONE place: cite the source of truth in the entry's `locator` and digest it in the `answer`, rather than copying it, so the answer can't drift out of sync with the source it summarizes.
10. Record the paraphrases people use to ask the same question as `alternatives` on the canonical entry (each `{ name, note }`), so a reader — or an agent matching on wording — who asks it a different way still lands on the one real answer instead of spawning a near-duplicate.
11. Keep one canonical entry per question. When two entries answer the same question, merge them: keep the better one, fold the other's wording in as `alternatives`, retire the duplicate (lifecycle `retired`), and link the survivor to it with a `replaces` edge (the `supersede` changeset op creates both at once) so a reader who finds the old one is redirected to the current answer.
12. Name a steward for every entry with an `attributed_to` edge to a Principal — a named owner is what keeps an answer from going stale. Record when the answer was last reviewed (a `last_reviewed_at` on the entry) and re-review on a cadence; ship the FAQ update in the same change as the work that changes the answer. A stale answer is worse than none — it sends people, and agents, confidently wrong.
13. Walk an entry through the lifecycle as it matures, which IS the KCS article state: `drafting` while the question is captured but the answer is unwritten or unvalidated (work in progress), `queued` once it is ready for review, `active` when it is the validated, in-force answer, and `retired` when it is archived or superseded. Completeness and quality gates apply once an entry is committed (`queued`/`active`); a `drafting` stub may be a bare question.
14. Log each result as a Log node: the question as it was actually asked in its `prose`, when in `happened_at`, and whether the FAQ resolved it in `outcome` (`succeeded` or `failed`). Link a resolved result to the entry that answered it with a `supports` edge — every use is a review (KCS 'reuse is review'), so the Logs that `supports` an entry are its reuse count and its evidence of health.
15. When a question is asked and no entry answers it, log that miss as a Log with `outcome: failed` and no `supports` edge — that orphan, and its raw question, is the demand signal for the next entry to write. When you write the entry that fills the gap, link it `derived_from` the Log(s) that revealed it. Don't write entries 'just in case'; let real questions pull them into being.
16. Don't store view counts or helpfulness tallies on the entry. The Logs are the atomic record of every result, so reuse, helpfulness (the share of `succeeded` outcomes), hot questions, and gap rate are all read off the usage stream — keep the entry the single source of the answer.
17. Cross-link related questions with `relates_to`, and group a narrower question under a broader topic question with `has_parent`, so the FAQ reads as a connected map rather than a flat list and a reader who lands on one entry can find its neighbors.
18. Agents: read `GET /<handle>/api/authoring-contract.json` and write with `POST /<handle>/api/changesets.json`. Create each entry as a Reference with its `answer`, its question `alternatives`, a `locator` to the source of truth, and an `attributed_to` steward edge in one changeset; log each result as a Log with its `outcome` and, when an entry resolved it, a `supports` edge to that entry.