dcfb411c3b
ProcedureIdentity requires a title and an authorising role, and neither was stored anywhere. The answer writer was asked for both, read them off whatever chunk retrieval happened to return, and returned "" whenever the header chunk was not among them. They belong in the row for the same reason doc_number and revision do: they are facts about the controlled document, established once when a human confirms the header, not something to re-derive per question from whatever text was retrieved. Denormalised onto every chunk exactly as the existing header fields are - ingest replaces every chunk of a source_file in one transaction, so they cannot drift within a document. complete() deliberately still requires only doc_number, revision and effective_date. A missing title makes an answer less useful; a wrong revision sends somebody to the wrong document. --assume-yes must keep refusing on the second and tolerate the first. controlled_copy_location is NOT in the schema. It is a site fact, identical on every row, and the one field where an invented value sends a person to a place that does not exist. It is CONTROLLED_COPY_LOCATION in api.env, defaulting to a string that names who to ask. The authorising-role pattern requires the colon: without it the lazy gap swallowed the field name and captured "role: Station Maintenance Supervisor" as the value, which the first run caught. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
45 lines
2.5 KiB
SQL
45 lines
2.5 KiB
SQL
-- =============================================================================
|
|
-- 007 - Document title and authorising role on doc_chunks.
|
|
--
|
|
-- WHY: ProcedureIdentity requires a title and an authorising role, and until
|
|
-- now neither was stored anywhere. The model was asked to supply them, read
|
|
-- them off whatever chunk retrieval happened to return, and returned "" when
|
|
-- the header chunk was not among them - which was most of the time, because
|
|
-- find_procedure ranked chunks by similarity to the question and a title block
|
|
-- does not resemble "how do I lift the interlock".
|
|
--
|
|
-- These belong in the row for the same reason doc_number and revision do: they
|
|
-- are facts about the controlled document, established once when a human
|
|
-- confirms the header at ingest, not something to re-derive per question from
|
|
-- whatever text happened to be retrieved.
|
|
--
|
|
-- Denormalised onto every chunk, exactly like doc_number/revision/
|
|
-- effective_date already are. The alternative is a documents table and a join
|
|
-- on the retrieval hot path; the corpus is small, ingestion replaces every
|
|
-- chunk of a source_file in one transaction (ingest.py rule 4), so the columns
|
|
-- cannot drift within a document.
|
|
--
|
|
-- NOT INCLUDED: controlled_copy_location. That is a fact about the site's
|
|
-- document management system, not about any one document - it would be the
|
|
-- same string on every row. It lives in CONTROLLED_COPY_LOCATION in
|
|
-- ~/ai/api.env instead. Letting the model invent it was how an operator could
|
|
-- be told to fetch a controlled copy from a place that does not exist.
|
|
--
|
|
-- Existing rows get NULL and keep working: citation() falls back to
|
|
-- section_title and then to source_file, which is what it did before. Re-run
|
|
-- `ai-ingest --all` to populate them.
|
|
-- =============================================================================
|
|
|
|
ALTER TABLE doc_chunks ADD COLUMN IF NOT EXISTS doc_title text;
|
|
ALTER TABLE doc_chunks ADD COLUMN IF NOT EXISTS authorising_role text;
|
|
|
|
COMMENT ON COLUMN doc_chunks.doc_title IS
|
|
'Document title from the confirmed header. NULL for rows ingested before '
|
|
'migration 007; re-ingest to populate.';
|
|
COMMENT ON COLUMN doc_chunks.authorising_role IS
|
|
'Role that authorises work under this document, from the confirmed header. '
|
|
'Advisory only - it does not grant anything and is not an authorisation '
|
|
'check.';
|
|
|
|
-- ingest_rw already holds INSERT/DELETE on doc_chunks, so no grant changes.
|
|
-- agent_ro already holds SELECT on the table, which covers new columns.
|