Record Metadata Fields¶
Anchor field-set / register — instantiates Context Anchor Design
A structured schema of fields stored alongside a record — author, created and modified time, version, and a pointer to the source — that travels with the record so its context is recoverable even when the body is copied, exported, or read in isolation.
A spreadsheet forwarded three hops loses everything the original folder, filename, and "you know who made this" once supplied. Record Metadata Fields is the structured carrier for a record's context anchors: a defined set of fields — author, created/modified time, version, source pointer, classification — stored with the record and designed to travel with it. Its defining property is that it is a schema, not a single label: it fixes which context every record of a kind must carry and stores those anchors in a uniform, queryable form, so context survives copying, export, and machine handling. Where individual anchor mechanisms each fix one axis, this one is the container that co-locates several and keeps them attached to the body they describe.
Example¶
An investigation team collects a screenshot as evidence. As a bare image file, it is nearly worthless six months later: no one can say who captured it, from where, when, or against which case. Record Metadata Fields makes it durable by attaching a defined field-set — captured_by, capture_time, source_url, case_id, tool_version, hash — populated at collection and carried with the file through every copy and export. When a colleague later opens the file in isolation, the anchors travel with it: the pointer back to the source system, the author, the time, the version of the capture tool. The schema is what guarantees this — every evidence item is required to carry the same fields, following the spirit of a standard like Dublin Core,[n1] which defines a common metadata vocabulary precisely so that context isn't invented ad hoc per record.
How it works¶
- Fix a field schema, not ad-hoc notes. Define the set of context fields every record of a kind must carry (author, times, version, source pointer), so context is uniform and queryable rather than improvised.
- Populate at the source and bind to the body. Capture the anchors when the record is created and store them with it, so they survive copy, export, and format changes instead of living in a folder name or a person's memory.
- Point back to the canonical origin. Include a source-record pointer so a copy read in isolation can be traced to the authoritative original.
Tuning parameters¶
- Schema richness — a minimal core (who / when / version / source) vs. an extensive field-set. More fields recover more context but raise the cost and decay rate of keeping them accurate.
- Required vs. optional fields — which anchors a record must carry to exist. Mandatory fields guarantee coverage but add friction at creation; optional ones fill unevenly.
- Population mode — automatic (system-captured) vs. manual (author-entered). Automatic fields are reliable but capture only what the system sees; manual fields catch tacit context but are the first to be skipped or falsified.
- Binding strength — embedded in the record vs. stored in a separate index. Embedded metadata travels with copies; an external index is easier to manage but can detach from the body it describes.
When it helps, and when it misleads¶
Its strength is durability under movement: a record carrying its own structured context can be copied, exported, and re-read in isolation without losing who, when, which version, and where-from — which loose annotations cannot guarantee at scale.
It misleads when the fields are present but wrong — metadata decays quietly (a "modified" date reset by a bulk export, an author field inherited from a template), and a populated-but-false field is trusted precisely because it looks systematic.[n2] Because the anchors sit beside the body rather than on its face, a reader acting in the moment may never see them — metadata is the archetype's canonical "hidden" store, the opposite of a Context-Aware UI Label. The discipline is to populate at the source, prefer system-captured fields for the anchors that must be trustworthy, and not assume a filled field is a true one.
How it implements the components¶
source_record_pointer— its signature field: the pointer back to the canonical source record, so a copy in isolation is traceable to its origin.version_anchor— a stored field fixing the version or state the record belongs to.time_anchor— created/modified/captured time fields carried with the record (the stored form; the typed, absolute stamping is Timestamping's job).speaker_author_anchor— an author/owner field naming the responsible party (the stored form of what Speaker Attribution marks in the body).
It does not make these anchors visible at the point of use (that is Context-Aware UI Label), draw the jurisdictional boundary (Location / Jurisdiction Label), or test whether the field-set is sufficient for an outsider (Context-Shift Walkthrough); it is the structured store that co-locates the anchors and carries them with the record.
Related¶
- Instantiates: Context Anchor Design — the structured carrier that stores and transports a record's anchor set.
- Consumes: the anchor values that mechanisms like Timestamping and Speaker Attribution produce; the schema stores them in uniform fields.
- Sibling mechanisms: Context-Aware UI Label · Version / Context Note · Timestamping · Speaker Attribution · Role Labeling · Location / Jurisdiction Label · Meeting Minutes Context Capture · Context Handoff Header · Context-Shift Walkthrough
Editorial Notes¶
Form Classification¶
Form family: Record, Log & Register
Rationale: Record Metadata Fields operates by binds uniform author, time, version, and source provenance fields to every created record. That concrete deployed or enacted form is Record, Log & Register under the frozen taxonomy.
Nearest alternative: Representation, Specification & Plan — Although Representation, Specification & Plan can support this mechanism, the frozen evidence makes its operative form the act that binds uniform author, time, version, and source provenance fields to every created record; the alternative is therefore secondary rather than defining.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Library & Information Science
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Authorship, date, version, and source metadata are canonical cataloging and archival schema elements.
Review resolution: Both blind reviewers agree that library_information_science is the primary origin. Explicit reconciliation of alternate origin disagreement, origin mode disagreement adopts reviewer_a's classification because authorship, date, version, and source metadata are canonical cataloging and archival schema elements. The resulting lineage records alternates=none, origin_mode=single_lineage, and domain_reach=multi_domain; these describe formative provenance separately from later applicability.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Dublin Core is a widely-used standard defining a small common set of metadata elements (creator, date, source, identifier, and others) for describing resources, so that context is captured against a shared vocabulary rather than reinvented per record. ↩
[n2] Metadata rot — the gradual divergence of a record's stored context fields from the truth, as bulk operations, migrations, and template inheritance overwrite or stale them. It is why a populated field is not automatically a trustworthy one. ↩