No representation for document handling classification

[donCarlosOne]

No representation for a document handling classification

Type: specification gap — information model
Target: v1.1.
Raised following: the implementation demonstration dry run of 11 September 2026.

Summary

The information model has no way to record the handling marking an owning organisation has applied to a document — SECRET, CONFIDENTIAL, TOP SECRET, OFFICIAL-SENSITIVE, RESTREINT UE, TLP:AMBER, or an internal corporate equivalent. Markings of this kind govern who may see a document and how it must be handled, and they travel with the document. A provenance record that omits them loses a constraint the receiving party needs.

use.classification is the nearest existing member and addresses a different question. This issue asks for a separate member, and asks that the two not be conflated.

What use.classification is

From prov-meta-1.0/json/data-provenance.json:

{
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "regulation": { "$ref": "#/$defs/confidentiality-regulation-type" },
      "evaluated":  { "type": "boolean" },
      "tool":       { "type": "string" }
    },
    "required": ["regulation", "evaluated"]
  },
  "minItems": 1
}

Its own description: "Indicate if the dataset includes data falling into the confidentiality classification. Each classifier must be evaluated as true/false/unknown."

The member is named regulation and its type is confidentiality-regulation-type, which reads as a regulatory instrument or regulated data category — HIPAA, POPIA, GDPR and similar — rather than as a handling marking. The evaluated boolean supports that reading: the question being answered is whether the dataset falls under a given regulation, not what marking it carries.

This issue does not propose extending or reinterpreting that member. Conflating a regulatory determination with a handling marking would damage both. A dataset can fall under POPIA and carry no marking; a document can be marked SECRET and fall under no data-protection regulation; both can be true at once and a reader needs them answered separately.

A related question, not a proposal

The JSON Schema gives no expansions for the confidentiality-code-type values — other, pci, pfi, phi, pi, sci, spi. I am not going to guess at them, and an implementer building against the schema alone cannot either. If the prose defines them, a pointer from the schema description would help. If it does not, they should be expanded. Worth splitting into its own editorial issue rather than resolving here.

What is missing

A handling marking is a different kind of statement from anything currently in the model. It is not a property of the content. It is an assertion made by a named organisation, under a named scheme, at a point in time, and it is subject to review and downgrade.

That gives it four parts the model has nowhere to put:

• the marking itself — the value, as the originating organisation wrote it;
• the scheme it belongs to — without which the value cannot be interpreted, since the same word means different things in different schemes and organisations routinely define their own;
• who applied it — the record already has source.issuer as precedent for naming an asserting party;
• when, and when it falls for review — markings are downgraded and declassified, and a marking with no date is of limited use to a receiving party.

Proposed shape

A sketch to give the discussion something concrete, not a proposed PR.

"handling-classification": {
  "scheme":        "string",   // identifier for the classification system
  "marking":       "string",   // the value within that scheme, opaque to DPS
  "asserted-by":   "string",   // organisation that applied the marking
  "asserted-date": "date-time",
  "review-date":   "date-time" // downgrade or declassification review, optional
}

marking stays opaque to DPS. The specification should not attempt to enumerate markings — national, alliance and corporate schemes will not fit a closed list, and a list that tried would be wrong within a year.

scheme is there so the marking can be interpreted, not so schemes can be compared. Equivalence between schemes is a hard problem with organisational and legal weight behind it, and is out of scope here.

The pattern is consistent with the model rather than novel in it: system on method-type, generation-method-item-type and purpose-type is already the sanctioned way to name the code system a value is drawn from.

Open questions for the TC

Where does it belong? Three candidates:

• use — a marking constrains use;
• source — a marking is a property of the artefact as received;
• set — the marking of the metadata record itself.

Note that the record and the data it describes may carry different markings. A record describing a SECRET dataset is not necessarily SECRET, and in several schemes the aggregation rules make that a live question. Whichever placement is chosen, the specification should be explicit about which artefact the marking applies to — which may argue for permitting it in more than one place.

Cardinality. A single artefact can carry markings under more than one scheme at once; a document marked under both a national and an alliance scheme is ordinary. An array is probably right.

Portion marking. Paragraph-level markings are standard practice in several schemes and do not fit a document-level field. Out of scope in my view, but worth recording as a known limitation rather than discovering it later.

Optionality. It should be optional throughout. Most adopters will have no marking to record, and a record without one must stay conforming.

Relationship to the custody issue

A handling marking is something the producer was told, read off a document, or applied itself. An ingesting system recording marking: "SECRET" is asserting something whose basis a reader cannot see — the same question raised in the transmission and custody issue, where the proposal is an optional statement of what a claim rests on. If that is adopted, a marking sits naturally under it.

A marking that changes is also a case where set.tracking.revision-history is load-bearing rather than decorative. The history is the only place a reader could see that the marking on a record was not always what it now says.

References

• prov-meta-1.0/json/data-provenance.json — use-type.classification, confidentiality-regulation-type, confidentiality-code-type
• prov-meta-1.0/prose/edit/src/schema-05-use.md — Use
• prov-meta-1.0/prose/edit/src/schema-03-source.md — source.issuer