Sign-Off Ownership for Held Chunks: Who Approves Which Source

Borrow the structure from financial approval routing, which has solved this problem for decades. An approval matrix is a table mapping request attributes to approvers, maintained as business data rather than buried in code, with every row carrying a fallback so that a gap never means "no approval needed" (approval workflow design guide). Commercial systems implement the same idea: Ramp describes matrices that map input criteria such as department, location and entity to outputs such as approvers, including amount thresholds where the lowest sufficient tier wins (Ramp approval matrices).

Translating that to held chunks, the input column is the source class and the output columns are the approver, the fallback and the escalation target.

Two rules make this table operational. First, the fallback must hold the same authority, which means the role is pre-approved to sign for that class, not merely senior in the org chart. Second, the escalation column is a person or role who is expected to answer when the first two are unavailable, because a blank cell in a matrix is a wildcard in many systems, and a wildcard that routes to nobody is a silent auto-approval.

Absence is where most release processes quietly break. The realistic sequence is a held chunk, a primary approver on leave, a fallback who has changed teams, and a deadline. Someone approves on the approver's behalf from a phone, and the audit trail now records a name that did not make the decision.

Controlled delegation fixes this without adding headcount. Rules worth enforcing, drawn from the same design guidance, are: a start and end date on every delegation with no open-ended grants, a scope limited by source class or volume, a delegate who could approve in their own right, no re-delegation chains, and a record that states "approved by A on behalf of B" (approval workflow design guide). The last rule is the one auditors ask for and the one most teams skip.

Timeouts deserve an explicit policy: a missed deadline escalates, it never auto-approves. That mirrors the invoice workflow pattern where reminders fire at half the target time and at the deadline, then escalate to a named deputy rather than to the void. For held chunks, a sensible default is a target of one business day for public web, two for licensed and internal, and no deadline at all for regulated data, where the clock belongs to the privacy review rather than the release queue.

Where does the escalation top out? Name a single accountable role, typically head of content or head of data, with authority to release at risk and obliged to log the reason. A named risk-acceptance path is better than an unstructured one, because it produces a record you can review later.

Sign-off is only meaningful if the approver checks specific things. Claude, who signs for licensed sources, is not reading prose quality; she is checking whether the license permits indexing by a language model and whether the chunk's redistribution differs from the source's. The content lead signing for public web is checking publisher identity and whether the text contains latent instructions.

That second check is not paranoia. Prompt injection through retrieved documents is the mechanism by which a page that merely looks like documentation can redirect a model's output, and the Promptfoo RAG poisoning plugin documentation lists the families to look for: direct injection, context manipulation, retrieval hijacking, data extraction and prompt leakage. It also explains why filtering alone is weak: embeddings may not capture a semantic attack, and traditional content filters miss sophisticated payloads.

A practical checklist for the approver, per chunk:

1. Is the source class correctly tagged, and does the tag match the row that routed this chunk?
2. For licensed material, is the governing clause recorded against the chunk ID?
3. For public web, is the publisher identifiable and free of impersonation signals?
4. Does the text contain anything that reads like an instruction to a model, a hidden link, or a pressure to contact an address?
5. If any of the above is unclear, is the chunk quarantined rather than approved with a note?

Quarantine is a real pattern, not a metaphor. Systems such as Tinybird route rows that fail schema validation into a per-source quarantine table where they are inspected and later recovered after a fix (Tinybird quarantine guide). Treat your held-chunk store the same way: inspectable, recoverable, and separate from the live index, so that releasing a chunk is a deliberate act and holding one costs nothing.

Detection can help the approver, not replace them. CleanBase's insight is that documents crafted for the same targeted questions tend to be semantically similar to each other, so they form cliques in a similarity graph over the knowledge base, and flagging those cliques catches malicious documents (CleanBase). An approver who sees "this chunk sits in a cluster of eleven near-duplicates from three domains" has a much better basis for a decision than one reading a single page.

Process documents are worthless if the tooling lets anyone with write access bypass them. Make the approval matrix a permission boundary, not just a policy page.

Access control should mirror the source classes. Enterprise retrieval guidance recommends enforcing access control at the chunk level and carrying source metadata, author, timestamp and version through every stage of the pipeline so that answers can be traced back to their source (Unstructured RAG pipeline best practices). The same metadata is what makes an approval auditable: if a chunk in the index has no approver field, the control was not enforced.

A workable permission split:

Two details matter more than they look. First, approvers must not be able to edit chunk text and approve it in the same step, which separates the requester from the approver as segregation of duties guidance puts it. Second, the matrix itself needs version control: record which version of the matrix routed each chunk, so that an audit can see the rule that applied at the time rather than the rule in force today.

There is a maintenance signal worth watching. When the same source class escalates every week, the primary approver is wrong for that class, or the class is misdefined, and the matrix needs an edit rather than another reminder. Governance drifting into manual, one-off scans is the usual early symptom of a control that no longer matches the data estate (signs governance is too manual).

Suppose a corpus ingests 12,000 chunks a month and holds 6 percent for review, which is 720 chunks. Split those by class: 400 public web, 180 licensed, 100 internal, 30 user-generated, 10 regulated.

Volume matters because it decides whether review is a job or a chore. At 400 public web chunks a month, one content lead spends roughly 20 chunks per working day on review, which is realistic at three minutes each (about an hour a day). At 180 licensed chunks, legal counsel reviews nine a day, which is fine until two of those chunks are copies of the same feed export; deduplicate before routing, and the number drops.

Now the absence case. If the content lead is away for ten working days, 200 web chunks accumulate. A pre-approved fallback with the same authority clears them at the same rate, and the release queue drains in the normal cycle. Without a fallback, those 200 chunks either wait (index freshness drops for two weeks) or get bulk-approved by someone unauthorised, and the audit log shows a decision nobody owns.

The escalation count is the metric to report. If 15 percent of web chunks escalate monthly, the primary role is overloaded or the classifier is misrouting, and either way the fix is a matrix change rather than an exhortation to work faster.

One further number: cost of a bad release. Because retrieval poisoning can succeed with a single planted document (CorruptRAG), and because attack success against undefended retrieval systems has been shown to be high in the PoisonedRAG line of work summarized in RAG-IDS, the expected cost of one unreviewed chunk is not proportional to its size. It is the cost of one wrong answer to every user who happens to ask the targeted question.

When the matrix spans several source classes and the review volume grows past what one approver can hold, a Quanta expert can pick up the classification and routing work and hand back a maintained matrix. See Quanta Experts.

Three habits keep this from rotting.

Write the matrix as data, version it, and test the routing at boundaries. The boundary question (does a licensed chunk that is also user-generated route to legal or to trust and safety?) is exactly the kind of edge case that breaks a matrix in production, and it is cheaper to answer in a table than in an incident. Financial workflow guidance is blunt about the same point: define boundaries precisely and version the matrix so an audit can see which version applied (approval workflow design guide).

Review the escalation log monthly, not the whole queue. Escalations and overrides are where the matrix disagrees with reality. Two or three of each per month is health; thirty means the rows are wrong.

Test the pipeline against poisoned documents on a schedule, using synthetic poisoned copies rather than real held chunks. The Promptfoo RAG poisoning workflow is a concrete way to generate poisoned variants of existing documents, add them to a test knowledge base, and scan for the intended results you defined. That test tells you whether the gate holds when the approver does everything right but the chunk is hostile.