____12DS — The gcpn-container-1.0 Schema: Overview

Trigger S6

The first real signature case (GVB signing) initially produced standalone .json files in the res/ directory — a working method that bloats the Git repo (AP finding: "that bloats the Git repo unnecessarily"). 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-1.0.

The Schema at a Glance

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

Artifact Uniqueness (Insight AP1)

Every 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`), not 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 bloating).
Supplement rather than create anew: Each new process step sets a flag, embeds the new artifact, updates summary — JSON artifacts already embedded remain immutable.
Revision security through Git: The container history resides in the Git history of the repo (commit hash = proof of integrity).
Mutable doc, immutable JSON artifacts: The container MD is editable (grows with the case); the JSON contents are immutable — a change = a new artifact with a 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-1.0 (.v7g.md) is the actual JSON schema for a digital original/source document — it catalogs the source doc via sha256 (document ID, identifies it always and everywhere, even when it migrates), 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 = case/process.

What the Two Identifiers Are For — V7GUID as Doc-Type Register, uuidV7 as Ref-Doc UID

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

Identifier	Register Role	Purpose (Determinism)
V7GUID	Doc-type register	Classify (what kind of artifact?), situate (in taxonomy/sphere), determine workflows and methodology — the class determines which procedures apply
uuidV7	Ref-doc UID (temporal revision security)	Instance identifier of the cataloging act with a 48-bit timestamp — when it was classified, sortable in chronological order

This seemingly apparent complexity (two identifiers instead of one) is precisely the lever for Git-repo-based compliance without vendor lock-in: Everything can be derived from the repos (determined deterministically) — not only doc states (SHA-256 chain, flags expression), but also history and changes (Git history of the container: 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	Insight	Schema Feature
AP1	Repo bloat from individual files	`sidecar` field; JSON fence embedding
AP2	Redundancy in repeated participants	`actor_ref` reference mechanics
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