____12DS — The gcpn-container-2.7 Schema: Overview

Trigger S6

The first real signature process (GVB signing) initially generated standalone .json files in the res/ directory — an approach that bloats the Git repo (AP finding: "this unnecessarily bloats the Git repo"). The finding led to the correction: All JSON artifacts in ONE container doc (.gcpn.md, permanent extension), and the container itself becomes the normative JSON schema — gcpn-container-2.7.

The Schema at a Glance

{
  "$schema": "https://gitcover.org/schemas/gcpn-container-2.7.schema.json",
  "container_id": "GCPN-SIG-YYMMDD-NNN",
  "docUid": "<deterministisch aus ts + doc-sha256>",
  "kind": "signature-process",
  "tenant": { … },
  "referenced_doc": { … },
  "actor": { … },
  "attendees": [ … ],
  "persons": { … },
  "retention": { … },
  "signature": { … },
  "events": { "flags_set": { … }, "events_result": 0, "enum_ref": "<uuidV7>" },
  "summary": { … },
  "prev_container": null,
  "next_container": null
}

Distinction: The GCPN is not an original doc and not a sidecar; a separate .gcpn.md.gc.md is omitted. The source document carries its own <artefakt>.<orig-ext>.gc.md; the container references it via referenced_doc (sha256) and carries its own GCPN-docUid.

Artifact Uniqueness (Finding AP1)

Each entity is described exactly once:

Artifact	Cardinality	Reference Mechanism
`referenced_doc`	1×	All further references sha256-based (no repetition of title/path)
`actor`	1× (per involved party)	Events/signature reference via `actor_ref` → `actor_id`
`retention`	1×	Per container, not repeated per artifact
`attendees`	n×	References (`actor_ref`/`tenant_ref`), no persons
`persons`	n×	Pseudonymized PII bridge
`signature`	1×	`actor_ref` + evidence references
`events`	1× (flags object)	Bits + `events_result`
`summary`	1×	replaces MD text repetitions

The Rules That Follow from the Finding

JSON always embedded (MD fence in the container) — no standalone .json files in the repo tree (avoid bloat).
Add rather than create anew: Each new process step sets a flag, embeds the new artifact, updates summary — already embedded JSON artifacts remain immutable.
Revision safety through Git: The container history is in the repository's Git history (commit hash = integrity proof).
Mutable doc, immutable JSON artifacts: The container MD is editable (grows with the process); the JSON contents are unchangeable — change = new artifact with new SHA.
Commits only by E1 (NO-AUTO-COMMIT).

The Source Document Is Cataloged via the Sidecar Schema

A separate "original-doc schema" is not necessary: The schema v7g-sidecar-2.0 (.gc.md) is the actual JSON schema for a digital original/source document — it catalogs the source doc via sha256 (document ID, always and everywhere identifies it, even when moving), locations (UNC history), v7g_taxonomy (class), and obsolescence/ retention. The container (referenced_doc) references it — two schema levels, no redundancy: Sidecar = source-doc cataloging, Container = process/procedure.

Why the Two Identifiers — V7GUID as Doc-Type Register, uuidV7 as Ref-Doc-UID

This also makes clearer what each of the two identifiers is needed for:

Identifier	Register Role	Purpose (Determinism)
V7GUID	Doc-Type Register	Classify (what kind of artifact?), categorize (into taxonomy/sphere), determine workflows and methodology — the class determines which procedures apply
uuidV7	Ref-Doc-UID (temporal revision safety)	Instance identifier of the cataloging act with 48-bit timestamp — when classification occurred, sortable in chronological order

This apparent complexity (two identifiers instead of one) at first glance is precisely the lever for Git-repo-based compliance without vendor lock-in: Everything can be derived from the repos (deterministically determined) — not only doc states (SHA-256 chain, flags expression), but also history and changes (container Git history: which steps were added when; sidecar history: classification records with timestamps). No proprietary system stores the state — the repo itself is the state, and any auditor can repeat the derivation with open tools.

Verification Without Redundancy

The verification routine (DS04) remains — it works with the manifest in the container: sha256sum per artifact against events.flags_set[].sha256 or referenced_doc.sha256; chain via chain_valid; facsimile SHA against the table in SIGNATURE_BLOCK.md.

Research Gain Protocol (AP)

AP	Finding	Schema Feature
AP1	Repo bloat from individual files	JSON fence embedding; `referenced_doc` (no separate sidecar field)
AP2	Redundancy in repeated involved parties	`actor_ref` reference mechanism
AP3	Retention/obsolescence multiple times	`retention` 1× per container
AP4	Text repetitions in the MD	`summary` artifact

Created: 260913 | Part III, Article ____12DS | Series: digital-signage