Git-native Profile

The Git-native profile is one implementation of Truth Machine semantics. It is useful when the current account is moderate in size, review latency is human scale, plain files are operationally desirable, and one atomic commit can carry the coherence boundary.

It is not suitable merely because a team already uses Git.

Reference mapping

Truth Machine meaning	Git-native representation
Evidence	Stable packet plus manifest and content hashes
Current truth	Typed current.toml selecting accepted record packets
Proposed change	Change packet against an exact canonical commit
Review identity	Staged proposal digest plus attributable acceptance
Accepted transition	One commit whose parent is the expected revision
Change history	Append-only change packets plus Git history
Governed read	Offline program reading canonical remote objects
Publication	Manifest tying artifacts to source tree and release record

Canonical state

The canonical branch and locally available remote-tracking ref are declared. The default reader reads that canonical object, not uncommitted worktree files. This prevents a draft from masquerading as accepted truth.

A separate explicit worktree mode may validate a proposal. Its output must say that it is proposed and must not be presented as current.

Packet stability

Use stable identifiers and paths. Do not move accepted packets into status directories or renumber them. Lifecycle belongs in typed metadata; Git history and supersession preserve chronology without breaking links.

Recommended packet shapes:

evidence/EV-.../
  manifest.toml
  source files or curated observation

records/NNNN-slug/
  record.toml
  README.md

changes/NNNN-slug/
  change.toml
  README.md

publications/NNNN-slug/
  publication.toml
  manifest.json

Atomic bootstrap

An empty repository has no prior revision against which to bind its own first substantive proposal. Establish a minimal seed commit first. The bootstrap change then names that commit as expected_revision, remains proposed while reviewed, and lands its accepted records, current selection, and change packet in one child commit.

Reader responsibilities

The governed reader should check:

• packet identities and lifecycle values;
• evidence and document hashes;
• source and change references;
• current-selection coherence;
• exact transition ancestry;
• human index agreement;
• canonical branch and remote-ref agreement;
• worktree separation; and
• generated publication drift.

It must never fetch, accept, commit, push, repair, or publish.

Scale boundary

Move durable state to a transactional store when account size, concurrency, latency, privacy, query shape, or write volume makes repository commits the wrong coherence mechanism. Preserve the semantic boundaries during that move; do not preserve Git merely because the reference implementation uses it.