Skip to main content
Version: MVP

Project Model

5 min readCore conceptUpdated 2026-05-19

What you'll learn

  • What a project profile is and why Craik builds one for every repository it touches.
  • The boundary distinction between mutable docs and immutable evidence.
  • What craik onboard emits and how runners consume it.
  • How project state changes propagate to case files and handoffs.

Project profile

The runner-readable view Craik builds from a registered repository. It combines local configuration, repository state, documentation boundaries, memory backend posture, policy posture, and known continuity records into a single typed object every Craik component speaks.

The project profile is operational, not descriptive. It tells an agent — human or model — concrete things it can act on:

  • Which repository is being entered.
  • Which docs are mutable.
  • Which paths are immutable evidence.
  • Which memory backend is configured.
  • Which tasks and handoffs already exist.
  • Which contradictions still need review.
  • Which validation commands are expected.
  • Which next actions are currently allowed.

When Craik builds a case file or a runner prompt, the project profile is the substrate every other layer is drawn against.

Mutable docs vs immutable evidence

Project profiles draw a clear line between documentation an agent may edit and evidence that should never be overwritten.

Mutable docs

  • README.md, files under docs/, and other configured doc roots.
  • Loaded into the case file as context.
  • Edits are allowed when the policy envelope grants write authority.
  • Touched by agents producing PRs, drafts, or reconciliations.

Immutable evidence

  • ADR directories (docs/adr/) and any path explicitly marked immutable in the project profile.
  • Loaded into the case file as evidence.
  • Edits require a separate, explicit policy grant.
  • Used by agents to justify decisions, not to mutate them.

This is the line that keeps a "doc reconciliation agent" from silently overwriting an ADR while updating the surrounding guides.

What craik onboard emits

craik onboard --project <project-id-or-name> prints a craik.agent_onboarding payload — the canonical, machine-readable introduction a runner sees on every task.

Field
Type
Description
project
project_profile
The full project profile — repo, branches, docs, immutable paths, validation commands.
policy_envelope
policy.envelope
Active policy posture: write authority, review gates, credential bindings, redaction settings.
docs_boundaries
boundary_set
Concrete lists of mutable doc roots and immutable evidence roots.
recent_handoffs
handoff[]
The last n handoffs for the project, so agents resume from real state.
unresolved_contradictions
contradiction[]
Open contradictions surfaced from memory or previous runs.
stale_risk_warnings
marker[]
Pieces of context the runtime believes may be out of date.
validation_commands
command[]
The verification harness the runner is expected to use (tests, linters, type-checkers).
stigmem_backend
backend_status
Whether Stigmem is configured and whether connection env vars are present. No credentials in payload.
known_traps
trap[]
Negative knowledge from previous runs — what not to do, with reasons.
allowed_next_actions
action[]
The actions policy + intent lock currently permit. The agent's menu.

craik onboard does not probe external services by default. Stigmem status reports whether the project is configured for Stigmem and whether connection environment variables are present — it never prints credentials.

Inspecting a project

craik project list

List all registered projects with their ids, names, and Git heads.

craik project show <name-or-id>

Print the full project_profile JSON.

craik onboard --project <name-or-id>

Print the craik.agent_onboarding payload — what a runner sees first.

How updates propagate

The project profile is the canonical source for case files, intent locks, and onboarding payloads. When you change a project — register a new immutable path, configure a memory backend, add validation commands — the next case file build reflects it. Existing handoffs aren't rewritten; they stay faithful to the project state at the time the run ended.

What's next