PUBLIC GUIDE — CHRONOSCRIPT ENTRY PREPARATION
1. PURPOSE
This guide explains how to prepare information for a Chronoscript draft. It applies to manual entry, JSON import and Chronoscript Structured Text. Preparing or importing data does not create a canonical Registry Record. Every imported source must be reviewed before the workflow continues.
2. CORE FIELDS
Record Type — one of EVENT, DECLARATION, PUBLICATION or CORRECTION.
Visibility — public, restricted or private. Finalized restricted/private records retain a minimal public registry manifestation so the canonical sequence remains continuous.
Title EN / Title FR — at least one title language is required.
Summary EN / Summary FR — concise factual description where useful.
Subject — principal object or subject of the event.
Registrant — party submitting the information to the service.
Creator — creator or originator when relevant.
Parties — identifiers or names of involved parties.
Event UTC — UTC date/time of the event when known.
Event DYPCLT — calculated from Event UTC when UTC is supplied. A conflicting manually supplied DYPCLT is rejected.
Reference — external or internal reference associated with the event.
Related LX — integers from 1 to 72.
Relations — structured links to other records or objects.
Validation Profile — currently basic.
3. JSON IMPORT
The machine-readable schema is published at /schemas/chronoscript-submission.schema.json. Example:
{
"schemaVersion": "0.1.0",
"recordType": "DECLARATION",
"visibility": "public",
"title": {"en": "Publication of document X", "fr": "Publication du document X"},
"summary": {"en": "Factual description.", "fr": "Description factuelle."},
"eventUtc": "2026-08-11T10:30:00Z",
"parties": ["NZ000-L0T0P0"],
"relatedLX": [1,55],
"validationProfile": "basic"
}
Event DYPCLT may be omitted when Event UTC is supplied; LXKeys calculates it. The imported JSON is normalized, checked and displayed for review before a draft is created.
4. CHRONOSCRIPT STRUCTURED TEXT
A plain-text source may use labelled fields:
CHRONOSCRIPT 0.1.0
TYPE: DECLARATION
VISIBILITY: public
EVENT UTC: 2026-08-11T10:30:00Z
TITLE EN:
Publication of document X
TITLE FR:
Publication du document X
SUMMARY EN:
Factual description.
SUMMARY FR:
Description factuelle.
PARTIES:
- NZ000-L0T0P0
RELATED LX: 1, 55
VALIDATION PROFILE: basic
The format is intentionally human-readable and deterministic. Unknown prose is not silently converted into canonical data. When automated assistance is used to prepare structured data, the resulting fields remain a proposal that must be reviewed.
5. REVIEW AND VALIDATION
After parsing, LXKeys presents the normalized fields, source SHA-256, parser version, warnings and errors. The operator reviews and may correct the fields before creating a DRAFT. DRAFT is the editable preparation state: record fields and evidence may be added, corrected or detached there. Once the record becomes SUBMITTED, its content and evidence are locked for review. Any later amendment requires an explicit audited return to DRAFT, followed by a new submission and validation cycle. The source does not bypass DRAFT, SUBMITTED or VALIDATION. Before READY FOR FINALIZATION, LXKeys checks the controlled vocabulary, required fields and UTC↔DYPCLT consistency. Final validation is repeated immediately before canonical finalization.
6. FINALIZATION
Only canonical finalization assigns a permanent Record ID and Registry Sequence. A finalized record is read-only. A later correction is a separate linked record. Import formats and APIs facilitate integration; they do not transfer canonical issuance authority.
7. SEMANTIC PROFILE VS VALIDATION PROFILE
Semantic Profile identifies the versioned meaning of a record and any profile-specific extension schema. In ordinary manual entry, LXKeys selects the compatible generic Semantic Profile automatically and does not expose raw extension JSON. Validation Profile is a separate validation-policy coordinate (currently basic) used to decide whether the draft may advance. These concepts are not interchangeable.
7. VERSIONED RECORD RELATIONS
Relations are available for all four fundamental record types. Control presents a relation selector and a target record. The 1.0.0 vocabulary is references, supersedes, revokes, amends, continues and corrects. A Correction action is a convenience shortcut that creates a CORRECTION draft with corrects prefilled; it is not the only way to relate records. Incoming/inverse graph context is derived and never rewrites prior records. See CHRONOSCRIPT-RELATIONS.
8. SEMANTIC PROFILE RESOLUTION
Daily manual entry does not expose semantic profile selection, profile version or raw semantic-extension JSON. LXKeys resolves the compatible generic profile internally. Specialized automated workflows use their own constrained profile contract.