Skip to content

Anthropic built Scion for itself. Carbon Forge is yours →

Carbon Forge
Get started
Menu
PlatformAEGISZaruComparePricingDocs Sign in

The Carbon SCM specification

The commit is a call. The record is the store. Git is an archive.

Carbon SCM is a source-control model in which the commit is a call, the record is the store, and git is an archive rendered from it.

Normative and self-contained: an implementation built from it alone is a conforming Carbon SCM, and Carbon Forge is its first implementation. Carbon SCM

Start free Request access

What always holds.

Entities, not files.
Pages, atoms, code trees and library entries, each with a chain of revisions.
Stored once.
Bytes are stored once per workspace by their SHA-256.
All or nothing.
A changeset commits whole, in one transaction, or not at all.
One trunk, flat lanes.
Lanes never branch from lanes; every lane composes over the trunk as it stands.
A cut never moves.
A cut names one snapshot forever.
Same record, same git.
Two conforming implementations render the same record to the same commit and tag ids.

How it works.

The seal

  • Every revision written in a changeset is sealed: a hash over its content, its metadata, its actor, its time and its predecessor’s seal, optionally signed with Ed25519.
  • The changeset’s own seal is the last write of its transaction, over every member revision.
  • A snapshot’s seal binds its manifest digest and the seal of the snapshot before it.
  • A verifier walks the chain newest first and reports valid, checked, where it broke, and whether every link was signed.

Lanes and landing

  • A lane holds page and atom substitutions, tree deltas with patches inside a file, library references, creates, deletes and moves.
  • Reading a lane composes it by replaying its live patches over the trunk; symbol sections are recorded alongside, advisory, never deciding a conflict.
  • Landing re-checks every resolution under lock and replays the lane as one changeset; the lane’s rows stay as the record of what landed.
  • An owned lane takes writes and its landing from its owner only.

The rendered archive

  • A commit’s message is the changeset’s intent, then the trailers Carbon-Changeset, Carbon-Tree-Revision, Carbon-Seal and Carbon-Manifest.
  • Its author is the actor’s id, never a display name; its committer is Carbon Forge.
  • A cut renders to the annotated tag refs/tags/nn/<cut>, which never moves.
  • A push re-renders main from the record and moves the remote fast-forward only.

Tokens and reach

  • An execution token is minted from a parent for one AEGIS execution, one lane and one tree path, and never mints another token.
  • Every write through it passes containment first, deny by default.
  • A non-member reads only the current revision of a public code tree; every other read answers as if the object did not exist.
  • No tool reads or returns a credential.

Twelve chapters.

  1. 0

    Introduction

    Four kinds of versioned entity in one workspace, stored by content, sealed, landed on one trunk through flat lanes, and rendered to git.

    • workspace
    • page
    • atom
    • code tree
    • blob
    • manifest
    • revision
    • changeset
  2. 1

    Data model

    Every persistent object belongs to exactly one workspace, and ids are allocated in increasing order, so a later write always has the greater id.

    • workspace isolation
    • revision id
    • lane patch
    • seal key
  3. 2

    Content addressing and the seal

    Bytes are named by their SHA-256, digests are taken over canonical JSON, and every revision, changeset and snapshot is sealed and can be verified link by link.

    • canonical JSON
    • manifest digest
    • seal
    • chain verification
  4. 3

    Trees and revisions

    A code tree is a manifest of files per revision, written whole or patched inside a file, and read on the server by diff, semantic diff, blame, grep and materialize.

    • file path
    • entry
    • trees.apply_patch
    • blame
    • materialize
  5. 4

    Changesets and the trunk

    A changeset is atomic: every revision, its seal, its audit rows and its hook events commit in one transaction, or none of them, and a protected trunk moves only by a lane’s landing.

    • changeset
    • intent
    • trunk
    • lock order
    • revert
  6. 5

    Lanes

    A lane is a flat, ordered list of patches over the trunk, composed when read by replaying its patches, checked for conflicts, compacted, and landed as one changeset.

    • lane
    • patch
    • composition
    • conflict
    • landing
    • lanes.compact
  7. 6

    Cuts and snapshots

    A snapshot is a sealed, chained manifest of every entity’s revision and every open lane’s patches at one instant, and a cut names one snapshot forever.

    • snapshot
    • manifest
    • timeline
    • cut
    • notes
  8. 7

    The git archive

    Each code tree renders to git byte for byte, one commit per revision and an annotated tag per cut, pushed fast-forward only to one remote.

    • archive
    • commit
    • tag
    • render
    • verify
    • push
  9. 8

    Identity, tokens and reach

    Every write records its actor, and an execution token confines one agent execution to one lane, one tree path and one life.

    • actor
    • role
    • preset
    • execution token
    • containment
  10. 9

    Hooks

    Each fact of the record is an event written in the transaction that makes it, delivered signed, with retries.

    • event
    • changeset.landed
    • lane.landed
    • cut.taken
    • signed delivery
  11. 10

    Conformance

    Every requirement is listed by number, and the test vectors are gathered byte for byte.

    • requirement
    • refusal sentence
    • test vector
  12. 11

    Sources

    Each chapter names the decision records it derives from, how they were reconciled, and the design choices the specification makes.

    • decision record
    • design choice

See the model run.

Start free Read the specification