Built gov-archive-api.php per USR369 direction, following live research (checked 08/28/26): FTS5 keyword search over SQLite, not a vector DB, is the correct tool for exact-token lookups (D-codes, filenames, system names) which is what gov MD file overflow content actually needs -- multiple independent 2026 sources confirmed FTS5 wins on this query pattern at near-zero cost vs. semantic/vector search which is built for vague paraphrase queries. Design: two new tables (gov_archive real content, gov_archive_fts FTS5 index, external-content pattern with auto-sync triggers) added to EACH SYSTEM'S OWN existing [NN]-sys.db -- not a shared file -- matching the platform's established per-system-DB architecture. One shared API file (systems/governance/gov-archive-api.php) handles all 11 systems via a system= param, each writing only to its own DB. Actions: ping/add_entry/search/list. Tested end-to-end on Master's own 10-sys.db as the pilot: added a real test entry, found ONE real bug via actual testing (ambiguous column name -- section_title exists in both joined tables, needed qualifying) -- not guessed, found by running it. Fixed, redeployed, re-tested -- search returned the correct entry with a real BM25 score and snippet. Cleaned up the test entry afterward (0 rows confirmed in both tables via a temp verification script, zeroed after use).