Chronicle Schemas define the structural and machine-readable contracts used to represent canonical Chronicle Entries and supporting Chronicle-owned records.
Phase VII completed Chronicle's production schema architecture: one universal Chronicle Base Schema, specialized Event-Type Profiles, governed Controlled Values, explicit Schema Versions, machine-readable schema validation, and compatibility rules that preserve older records without silent structural rewriting. Phase VIII applies those contracts through Chronicle's institutional Validation and Entry Production Procedure, which have now been exercised in production.
Phase VII is complete. Chronicle now has a production Base Schema in both human-readable and machine-readable form, a production Certification Event-Type Profile, and a validated two-layer schema stack.
The canonical historical-preservation object is the Chronicle Entry. Supporting schemas exist only where a distinct Chronicle-owned function requires separate structure.
Chronicle schemas define Chronicle-owned records only. Authoritative Suite objects are referenced rather than redefined, and reference does not transfer authority.
The Chronicle Base Schema defines only universal Entry structure. A field is Required by the Base Schema only if every production Chronicle Entry needs it.
Event-Type Profiles specialize the Base Schema for specific Occurrence classes without creating competing canonical Entry objects.
Enumerated meaning is governed through the Chronicle Controlled Values Registry rather than invented independently inside each schema.
Machine-readable schema validation tests structural conformance to the Base Schema and applicable Event-Type Profile. Chronicle Validation is broader: it also tests Controlled Values, identifier requirements, authoritative references, date / time rules, Relationship integrity, Provenance, Correction / Version consistency, Verification dependency, authority boundaries, and publication readiness.
Every production Chronicle record remains associated with the Schema Version that governed it. Schema Version remains distinct from record Version.
Schema evolution must preserve backward interpretability through explicit compatibility, deprecation, migration, and historical-preservation rules.
The Chronicle Base Schema is the universal structural contract for every production Chronicle Entry.
Conditional fields support Event-Type Profiles, originating system where required by a Profile, authoritative references, Sources, Evidence, Relationships, Corrections, prior-Version linkage, publication timestamps, maintenance timestamps, and limitations where applicable.
The Base Schema intentionally does not require every architectural concept Chronicle may ever use.
These concepts belong in procedure, Historical Context, Event-Type Profiles, supporting records, Validation artifacts, or later schema evolution where operational need justifies them. In particular, Validation State is not embedded as a universal Base Schema field in Version 1.0.0.
A Profile may make conditional Base Schema fields Required, restrict Event Type, require authoritative references, strengthen Provenance, constrain Relationships, add Validation rules, or impose publication prerequisites.
The Certification Event-Type Profile is Chronicle's first production Event-Type Profile.
It specializes the Base Schema for qualifying certification-related Occurrences and
requires event_type_profile, originating_system = certifier,
non-null event_date, and authoritative certification references meeting
the Profile's structured authority requirement.
Production schemas reference approved Controlled Values.
Candidate vocabularies such as Source Role, Evidence Relationship, Preservation State, and certain actor roles remain intentionally unfrozen until production use proves the need.
The current schema family includes the production Chronicle Base Schema, Chronicle's first production Event-Type Profile, its Phase VII profile-validation report, and three reconciled supporting schema specifications.
The Certification Event-Type Profile is published as a three-file Profile package: public landing page, human-readable specification, and machine-readable validation profile. Supporting JSON schemas should be created only after their human-readable specifications are tested against real production supporting records.
Open Certification Event-Type Profile →Defines Chronicle-owned Source Records using the approved Source Type vocabulary, required Provenance, stable references, limitations, Version lineage, and authority boundaries.
Defines Chronicle-owned Evidence Records using the approved Evidence Type vocabulary, Entry / claim linkage, required Provenance, limitations, integrity information, and Version lineage.
Defines Chronicle-owned Correction Records using approved Correction Types and mandatory preservation of original information, corrected information, Correction date, reason, affected fields, and resulting Version.
Verification, Validation, Publication, Provenance, Relationship, or Version artifacts should receive separate schemas only when production requirements justify distinct, independently governed records. Phase VIII intentionally keeps the first Validation implementation lightweight and procedural rather than creating a new canonical Validation object.
Production Chronicle records distinguish schema identity, Schema Version, and record Version.
Backward-compatible changes may add Optional fields, clarify documentation, or introduce new Profiles without invalidating existing records.
Breaking changes include removing Required fields, renaming Required fields, changing field meaning or type, making Optional fields Required, or changing identifier or Version semantics.
These functions remain institutionally distinct.
The production schema stack is complete and has been exercised through Chronicle's Phase VIII operational layer and first canonical production Entry.
Chronicle now uses two related but distinct validation layers.
A machine-readable schema PASS is necessary where the machine-readable Entry is required, but it does not by itself establish overall Chronicle Validation PASS.
The production schema stack has now governed a real Chronicle Entry: CHR-2026-0001 Entry Version 1.
The production case confirmed the intended two-layer model: machine-readable schema conformance is necessary where applicable, while overall Chronicle Validation also evaluates institutional rules that schema alone cannot establish.
Chronicle schema architecture should remain minimal, explicit, version-aware, machine-readable, and durable.
The goal is not schema proliferation. The goal is one coherent structural language centered on the canonical Chronicle Entry with only the supporting schemas production actually requires.