In a service-bulletin retrieval index, how do you separate submitter-authored metadata from pipeline-assigned metadata?

## The audit is per field, not per index An index payload looks homogeneous - one flat object of metadata beside each chunk - which is exactly why this analysis gets skipped. The fields have wildly different origins, and the only way to know what a predicate over them establishes is to trace each field back to the moment it was written. Three classes are worth separating. **Parsed from the artefact.** Front matter at the top of the file, embedded document properties, a header table, a fragment of the filename, a value extracted from the body by a rule. Whatever the submitter wrote is what the index holds. A predicate over these fields tests conformance of a self-description. **Assigned by the pipeline at receipt.** The arrival timestamp, the source connector or bucket, the authenticated account the upload came from, a content hash, an internal document id. These are created outside the artefact. A document author cannot write them - though note the residual influence: they choose when to submit, so an arrival timestamp is under their timing control, and an account field is only as meaningful as the portal's account provisioning. **Derived from the caller at query time.** A scope computed from the session or the requesting identity. Nothing written inside a document can influence a value produced from whoever is asking. This is the only class an author is structurally locked out of. ## Reading a result set Given candidate rows and their metadata, the mechanical check is: for each key in the predicate, which of the three classes is it in? A predicate composed entirely of class-one fields narrows using the adversary's own text. That is not a subtle failure - it is the filter doing the sorting on the plant's behalf, because untidy legitimate rows fail a conformance test that a purpose-written row passes exactly. The tell in a payload is often structural rather than semantic. Fields that mirror the document's own vocabulary, in the document's own casing, with the document's own optionality (sometimes present, sometimes null) came out of files. Fields that are uniformly populated across every row, in one canonical format, were produced by code. ## What each class proves, stated carefully - A declared status proves what its author typed in that slot. It does not prove an approval happened. - A declared effective date proves what its author typed. It does not prove the guidance is in force. - An arrival timestamp proves when bytes reached the pipeline. It does not prove the content is current, and it does not prove anybody read the content. - A submitting account proves which credential authenticated an upload. It does not prove a human vetted the file, and it does not prove the account belongs to the party the document names. - A content hash proves the bytes were not altered after receipt. It says nothing about whether they should have been trusted before it. - A session-derived scope proves something about the asker, which is why an author cannot aim at it. Getting the direction of any of these backwards encodes the exact misreading that makes the family work. ## The intermediate cases that decide interviews Normalisation at ingest is the interesting middle ground. If the pipeline rewrites a declared value - canonicalising a model string, mapping declared status tokens through a lookup, refusing a date it cannot parse - the stored field is no longer a verbatim copy, and some malformed plants stop being eligible. That is real, and it is worth naming, but it is a change of format, not of provenance: a submitter who writes a well-formed conformant value still gets that value into the payload. Do not overclaim it. Cross-referencing is the other case. A field populated by looking the document up against a register held outside the submission path has a different provenance from a field the document declared, even if the two carry the same name. The question is never what the field is called; it is what wrote it. ## Why this is the senior version of the question Anyone can say a filter is only as good as its source. The production skill is doing the field-by-field trace on a real payload, resisting the pull of names that sound authoritative, naming the residual influence in the second class rather than declaring it clean, and stating precisely what each surviving field lets you claim.