Organization Governance, Grants, and Structural Evolution

The genome is the Git-tracked source code defining both your application and its governing organization under dna/org/ (topology, constitutional law, purpose, charter, model routing, and workflow definitions), alongside the toolchain-managed runtime in vendor/dna/. Every change to the genome is verified by the compiler (hale check --matrix .) and evaluated as a Review candidate—decided automatically by the Leader when within its dna::Grant, or escalated to the human Board. Secrets and operational state never live in the genome; they live in the vault and Postgres memory.

# 1. Ratify the project's initial purpose and seeded practice families
hale dna review purpose approve --as alice
hale dna review design approve --as alice

# 2. Preview and propose a multi-step organizational batch
hale dna apply team.batch --dry-run
hale dna apply team.batch --as alice

Genome File Layout

File / Directory	Purpose	Required Change Class & Authority
Application (`main.hl` and its seed)	The application supervised by the organism (the heart)	`application`, `feature`, `refactor`, or `docs` (Leader within grant, else Board)
`dna/org/main.hl`	Organization entrypoint: `dna::Dna` substrate, `dna::Leader`, `dna::Grant`, review policy, and NATS JetStream (`nerves`) bindings	`organization` (Board)
`dna/org/law.hl`	Constitutional claims (`constitution Org`) verified at compile time	`organization` / `law_touched` hard boundary (Board)
`dna/org/purpose.hl`	Single-sentence project purpose read by reviewers and the Leader	Ratified by the initial `purpose` Review; amended via `organization` change
`dna/org/charter.hl`	Architectural brief and planning rules for the Leader	`organization` (Board)
`dna/org/models.hl`, `dna/org/work.hl`	Model backend catalog, spend budget, and leg performers (Legs, hands and voice)	`organization` (Board)
`dna/org/own_workflows.hl`	Custom project workflow definitions (The spine)	`organization` (Board)
`vendor/dna/`	Toolchain-owned DNA core library (DNA, the building block)	Updated exclusively by `hale dna upgrade` (never edited by hand)

You can edit genome files directly and run hale check --matrix . to verify both the application and dna/org against their respective constitutions (Constitutions), or request changes through hale dna task create so the organism prepares a verified candidate with diffs and evidence (One task, end to end).

The purpose

dna/org/purpose.hl declares a single sentence stating what the codebase is meant to achieve:

// dna/org/purpose.hl — the declared purpose (project-owned).
//
// The first governed workflow is the baseline review: the Review
// named `purpose` ratifies THIS text (its subject digest is the
// sha256 of PURPOSE). Change the text and the Review's digest
// together, or the verdict is refused as stale.

const PURPOSE: String = "refproj: keep the application correct, reviewable and explainable; every change is staged, reviewed, and never applied by the organism itself.";

fn purpose() -> String {
    return PURPOSE;
}

hale habitat graft generates dna/org/purpose.hl and opens the purpose Review against its SHA-256 digest. Edit PURPOSE to match your project before ratifying it with hale dna review purpose approve --as <you> (Getting started). The Leader includes this string in its context every time it plans a task or evaluates a Review.

The charter

dna/org/charter.hl defines the Leader’s architectural brief:

// dna/org/charter.hl — the leader's brief (project-owned; generated by
// `hale habitat graft`). The leader reads this, the purpose, the law and
// the ratified design before it plans an ask and before it decides a
// Review. Change it as you would any part of the organism: through a
// reviewed change.
// …
fn charter() -> String {
    return CHARTER;
}

The default charter instructs the Leader to act as the organism’s architect: it classifies incoming tasks (whether an ask targets the organism, an appendage, a product, or a human role; which change class applies; and whether to split it into multiple tasks) without widening the scope of what was requested. Before planning a task or deciding a Review, the Leader assembles its system brief in strict order:

CHARTER (dna/org/charter.hl)
PURPOSE (dna/org/purpose.hl)
LAW (dna/org/law.hl)
PRACTICES (all ratified practices bound to org in Postgres memory)

Practices

A practice is a named operational rule ratified by the Board. Ratified practices are injected into the Leader’s brief and worker hats (hale dna work brief), and cited by reviewers. Unratified proposals have no effect.

hale habitat graft seeds three practice families as pending Board Reviews, alongside proposals for the repository’s structural positions (holes):

Family	Seeded Practices & Mandates	Scope
`design` (8 practices + 3 mandates)	`principles`, `evolution`, `structure-follows-intent`, `standard-equipment`, `signals`, `signaling`, `optimize`, `software-delivery`; `mandate-leader`, `mandate-editor`, `mandate-agent`	Organizational architecture: minimal structure, clean boundaries, and evidence-driven growth
`operating` (7 practices)	`one-store-per-step`, `row-first`, `readings-never-act`, `legs-hold-nothing`, `deploy-settles-on-pulse`, `the-forge-decides`, `optimize-cadence`	Runtime execution invariants and the daily `optimize-walk` schedule
`using` (7 practices)	`propose-review-ratify`, `change-classes`, `ask-the-leader`, `cut-structure`, `read-the-record`, `evidence-first`, `bind-knowledge`	Operator and contributor workflow conventions (seeded even when grafting with `--no-library`)

A mandate (mandate-<role> or mandate/<position>) is a practice bound to a specific position node in the graph. It defines what that position may decide, what it is forbidden from doing, what contracts or axioms it cites, and what it must escalate. When hale habitat graft proposes positions under holes, each position Review is immediately followed by its mandate Review; once ratified, the mandate appears in the hat of every worker claiming work as that position.

$ hale dna review
32 pending review(s) of 32
  purpose — the declared purpose, the Board's to ratify first:
      k:3870910f5de4 — ratify the declared purpose?
      decide one with `hale dna review <id> …`, or all pending with `hale dna review purpose approve|reject`
  design — 11 seeded practice(s), each its own Review:
      k:05cecb18af4e — ratify the design practice `design/software-delivery`: For an appendage or a product: process boundaries first (what runs, fail…
      …
      decide one with `hale dna review <id> …`, or all pending with `hale dna review design approve|reject`
  operating — 7 seeded practice(s), each its own Review:
      k:33be310ddba8 — ratify the operating practice `operating/one-store-per-step`: a workflow step writes to exactly one store, by that store's one writer,…
      …
  using — 7 seeded practice(s), each its own Review:
      k:8c1f6a4e2d70 — ratify the using practice `using/propose-review-ratify`: nothing is in force until the Board says so. A change to the organi…
      …
  holes — 6 hole(s) the repository leaves, each its own Review:
      k:d51a712f169e — ratify the position `board` under the purpose: it ratifies what this organization becomes
      …

Approve an entire group with hale dna review design approve --as <you> (which records an individual verdict for each Review in the group). Ratifying operating/optimize-cadence also declares the daily optimize schedule (Schedules).

Proposing and Amending a Practice (`hale dna practice`)

Anyone can propose a new practice or supersede an existing one:

hale dna practice propose acceptance/expense-receipt \
    --text "An expense closes with its receipt.
evidence: required" \
    --because "three bills arrived without receipts"

practice propose writes a practice.requested row (--as <who> overrides the author). When the organism is running, it opens a Board Review and prints:
```
practice acceptance/expense-receipt proposed by alice as sha256:…; the Board ratifies it: `hale dna review k:… approve --authority board`
```
Amending a practice (--supersedes <digest>): Pass the full or short SHA-256 digest (sha256:3122d) of an active practice. The CLI validates the target digest immediately (rejecting unknown, ambiguous, or inactive digests). When the Board ratifies the new version, the superseded version automatically transitions to retired (if rejected, the prior version remains in force).
Inspecting practices: Run hale dna practice to list all practices and their states (awaiting the Board, in force, declined, retired).

Grant and autonomy

Autonomy is delegated through an explicit dna::Grant inside dna/org/main.hl—written by the Board, held by a position (such as the Leader), and never widened at runtime:

            boundary: dna::AutonomyBoundary {
                child: "refproj",
                grant: dna::Grant { child: "refproj", classes: "refactor docs", max_magnitude: 4, review: "pre" }
            },
            review_policy: dna::OrgPolicy { },

classes: Space-separated list of change classes the Leader is permitted to decide.
max_magnitude: Maximum sum of the candidate’s semantic magnitude vector (see below). Any candidate exceeding max_magnitude escalates to the Board regardless of class.
review: Review timing mode—"pre", "post", "sampled", or "audit". "pre" requires a Review verdict before applying the candidate; the other modes allow candidates with sufficient mechanical evidence to be released and applied first if permitted by review_policy.

Because the grant is a Hale struct literal in dna/org/main.hl, modifying it is an organization change that always requires Board approval.

Change Classes

When the Leader plans an incoming task, it assigns a change class (defaulting to application if unspecified; any edit touching dna/org/ is forced to organization, and any edit touching fleet source or hale.toml is forced to topology via mutation.topology):

Change Class	Target Scope	Deciding Authority under `OrgPolicy`
`docs`, `refactor`, `feature`, `application`	Application source code	Leader if the class is in `grant.classes`, magnitude `<= max_magnitude`, and no hard boundary is crossed; otherwise Board
`organization`	`dna/org/` (positions, routing, grants, models, workflows)	Board
`constitutional`, `process-policy`	Constitutional or governance policy changes	Board
`topology`	Fleet seed source or `hale.toml` manifest (`mutation.topology`)	Board

Semantic Magnitude Vector and Hard Boundaries

Every candidate is measured from its semantic diff (hale model diff) across ten orthogonal dimensions (dna/core/types.hl) rather than collapsed into a heuristic confidence score:

Dimension	Condition in Semantic Diff	Weight Added to Sum	Hard Boundary?
`loci`	Each locus declaration added, removed, or modified	`+1` per locus	No
`contract_change`	Any parent-facing contract modified	`+4`	No
`effects_widened`	A locus reaches a new effect class	`+4`	Yes
`law_touched`	A constitutional claim is added, removed, or changes outcome	`+6`	Yes
`placement_change`	Thread/pool `placement { }` facet changed	`+2`	No
`ownership_crossed`	Locus ownership hierarchy crossed	`+3`	Yes
`state_migration`	A locus’s `params` fields changed	`+3`	No
`irreversible`	Locus `params` changed or a declaration was removed	`+5`	Yes (when combined with `external_blast`)
`external_blast`	Newly reached non-intrinsic effect class	`+2`	Yes (when combined with `irreversible`)
`novelty`	`3` until the lineage has applied its first change, then `1`	`+3` or `+1`	No

The four hard boundaries (law_touched, effects_widened, ownership_crossed, and irreversible + external_blast) can never be auto-released by a grant and always require Board review under OrgPolicy.

Evidence Scoring and `dispose()` Rules

Before evaluating disposition, any candidate that fails hale check or violates a fleet claim is immediately denied (mutation.deny). Candidates in seeds without Hale source always require human review.

For passing candidates, mechanical evidence points are summed:

check_clean: +1
verify_clean: +1
tests_pass: +2
replay_ok: +2
rollback_rehearsed: +2
Each independent review: +2

The pure function dispose(grant, class, magnitude, evidence) evaluates five rules in order:

Crosses any hard boundary -> review (mutation.review)
class is not listed in grant.classes -> escalate (mutation.escalate)
magnitude.sum > grant.max_magnitude -> escalate (mutation.escalate)
evidence < magnitude.sum + (2 * magnitude.novelty) -> stage (mutation.stage)
grant.review == "pre" -> review (mutation.review); otherwise -> release (mutation.release)

Because mechanical evidence totals at most 8 (1 + 1 + 2 + 2 + 2) and a fresh lineage has novelty = 3 (requiring at least sum + 6 evidence, which for any non-trivial change is >= 9), no candidate in a new lineage is ever auto-released before at least one change has been reviewed and applied.

Who is asked

The review_policy maps the disposition and change metadata to a required authority rank (board > leader > supervisor > reviewer). Under dna::OrgPolicy, the Board is required for all hard boundaries, the four Board change classes, and any escalate disposition; all other Reviews within the grant are assigned to the leader (which evaluates the candidate via an LLM call and records its reasoning in the record).

When the Postgres memory graph defines active reviews edges for the touched files and those reviewer positions are held by people, those human signers take precedence and the Leader never decides the Review (Route and signers).

Post-Review Mode for Trusted Refactors (`dna::PostReviewRefactors`)

For mature codebases where small, reversible refactors can be applied immediately and reviewed asynchronously afterward, configure dna::PostReviewRefactors with review: "post":

import "vendor/dna" as dna;

// Post-review for refactors: applied first, reviewed after.
fn trusted_policy() -> dna::PostReviewRefactors {
    return dna::PostReviewRefactors { };
}

fn trusted_boundary() -> dna::AutonomyBoundary {
    return dna::AutonomyBoundary {
        child: "refproj",
        grant: dna::Grant {
            child: "refproj",
            classes: "refactor",
            max_magnitude: 12,
            review: "post",
        }
    };
}

Pass review_policy: trusted_policy() and boundary: trusted_boundary() to dna::Dna. PostReviewRefactors blocks pre-verdict release for every class except refactor. A qualifying refactor is applied, expressed, and observed in the runtime window immediately, while opening a post-review (post-review: applied m4 (refactor): …?) requiring reviewer authority. If the reviewer rejects the Review, the organism automatically rolls the genome back to the base commit.

Grant Ceilings and Monetary Grants

Parent Ceiling (ceiling): dna::Dna accepts an optional ceiling: dna::AutonomyBoundary. When set, the Leader’s boundary.grant is intersected with ceiling on every evaluation (taking the intersection of classes, the minimum max_magnitude, and the stricter review mode). If a grant is configured wider than its ceiling, dna::Dna logs grant.refused at startup and clamps it to the ceiling.
Monetary Grants: By default, a dna::Grant specifies no currency and permits zero financial spend. To authorize bounded expenditure:
```
import "vendor/dna" as dna;

fn books_grant() -> dna::Grant {
    return dna::Grant {
        child: "books", classes: "docs", max_magnitude: 4, review: "pre",
        amounts: "USD 500.00",
        window_amounts: "USD 2000",
        window: "week",
        counterparties: "suppliers",
        routes: "operating-account",
        expires: 1798761600
    };
}
```
amounts caps single-operation spend, window_amounts caps cumulative spend per window, and expires sets a Unix timestamp expiration (0 for no expiration). The spine reserves funds against the grant before execution (spend.reserved), and dna/org/law.hl forbids any position from reaching a money effect outside the substrate.

The law

dna/org/law.hl encodes the organization’s non-negotiable architectural invariants as a Hale constitution adopted by dna/org/main.hl (claims { adopt Org; }):

group board = { dna::Board };
group leader = { dna::Leader };
group substrate = { dna::Dna };
group positions = { dna::Leader, dna::SourceEditor, dna::WorktreeTools, dna::LegRelay, dna::RelayReplay, dna::HumanWorkGateway, dna::ServicePerformer, dna::ScriptedPerformer };
group editors = { dna::SourceEditor, dna::WorktreeTools };
group knowledge = { dna::Knowledge, dna::MemoryKnowledge };
group credentials = { dna::CredentialSource, dna::HostedCredential };

constitution Org {
    // …
    apply_only_through_the_substrate: forbid reaches(positions, effects(genome_apply)) avoiding substrate;
    // …
    editors_never_commit: forbid reaches(editors, effects(repo_write));
    editors_never_touch_worktrees: forbid reaches(editors, effects(worktree_io));
    editors_never_apply: forbid reaches(editors, effects(genome_apply));
    editors_never_learn: forbid reaches(editors, knowledge);
    // …
    leader_never_commits: forbid reaches(leader, effects(repo_write)) avoiding substrate;
    leader_never_touches_worktrees: forbid reaches(leader, effects(worktree_io)) avoiding substrate;
    // Credentials are read from their source into sealed loci and never returned.
    credentials_sealed: require sealed(all credentials);
    // …
    money_only_through_the_substrate: forbid reaches(positions, effects(money)) avoiding substrate;
}

hale check verifies these claims statically across both direct method calls and bus topic subscriptions:

Editors (SourceEditor, WorktreeTools) can never commit to the repository, manage worktrees, apply genome mutations, or modify knowledge.
The Leader can never write to the repository or worktrees directly—its verdicts only reach LocalGit through the substrate (dna::Dna) gate (avoiding substrate).
Credentials (CredentialSource, HostedCredential) are confined inside @sealed loci (require sealed(all credentials)).
Monetary effects can only be reached through dna::Dna.

If any code change wires a forbidden handle or bus path (or if an avoiding substrate gate is bypassed), hale check dna/org fails at compile time and prints the exact call/bus witness chain:

$ hale check dna/org
…/dna/org/law.hl:31:5: type error: claim `leader_never_commits` violated: `leader` reaches `effects(repo_write)` — witness: `dna::Leader::on_requested` -(publishes "dna::ReviewVerdict")-> `dna::Review::on_verdict` -(publishes "dna::ReviewSettled")-> `dna::Dna::on_review_settled` -> `dna::Dna::rollback_to_base` -> `dna::MutationGateway::rollback` -(dispatches dna::Repository.rollback)-> `dna::LocalGit::rollback`

See Claims & the law and Constitutions for the full claim language.

Positions and `fill`

While dna::Board and dna::Leader are loci in dna/org/main.hl, organizational positions (board, <part>/dev, <part>/reviewer, <deployment>/operator) are nodes in the Postgres memory graph (hale dna show org), and assigning a person or firm to a seat creates a ratified holds edge (Memory and the record).

When hale habitat graft initializes a project, it proposes the structural positions implied by the codebase under the holes Review group. Until the Board ratifies those holes (hale dna review holes approve), the positions do not exist in the graph and cannot be filled directly:

$ hale dna fill board alice
hale dna: fill: `position:board` is no position or organization the record states or proposes

(To propose and fill initial holes in a single step at graft time, use hale habitat graft --with <pack>—see A pack at the graft.)

Assigning a Holder (`hale dna fill`)

Once a position is stated or proposed in the record, propose a holder with:

hale dna fill <position> <holder> [project] [--as <who>]

Validation: <holder> must be an active (non-retired) person known to the record or a member of an owning organization, and never a reserved system name.
Equipment (equipment.roles): When a position governs an API contract (spec/<Stem>.description.json or hale check --api), the graft attaches the contract’s requires roles as position equipment (requires: [editor] on <app>/dev, requires: [reviewer] on <app>/reviewer). hale dna fill prints equipment: <roles>, and hale dna show org displays {mandate: ratified; roles: editor} (issuing an OIDC token for those roles remains the identity provider’s responsibility).
Ratification: hale dna fill writes a hold.requested row, and the organization opens a Board Review under the holds group. Because seating a person is a governance action rather than a code change, the person who proposed the fill may also approve the Board Review (hale dna review holds approve).
Reviewer / Developer separation: A part’s dev and reviewer positions cannot be held by the same person. In single-user local mode (dna.trust = local), fill prints a warning; on a shared record, both the CLI and Postgres memory refuse the hold (hold.refused).
Multi-firm ownership: On a shared record across multiple firms, fill also assigns position ownership to an organization and enrolls people into an organization (a position may have at most one owning organization, and a person may belong to at most one organization):
Terminal window
```
hale dna fill org/collections organization:north   # organization:north owns position:org/collections
hale dna fill organization:north bob               # bob is a member of organization:north
```

Opening a New Position (`hale dna position open`)

To propose a new position and its mandatory mandate at runtime:

hale dna position open api/steward \
    --mandate "decides how the list's api reads; may not change the browser; cites the README's axioms; escalates a new surface to the Board" \
    --under api \
    --text "keeps the list's api"

--mandate is required, and --under must name an existing seed, work part, position, or process in the graph. The organization opens a single Board Review under positions that ratifies both the position:api/steward node and its bound mandate together.

Structural Batch Operations (`hale dna apply` and `hale dna vacate`)

Instead of opening separate Reviews for every position, mandate, and holder, you can group structural mutations into a batch file and propose them as a single atomic Board Review (changes group):

# team.batch — the api team
open api/dev | Decides: how the api is built. May not: sign its own changes. Cites: the contract. Escalates: to the Board.
open api/reviewer under position:api/dev | Decides: whether a change is ready. May not: write it. Cites: the change. Escalates: to the Board.
fill api/dev ada
fill api/reviewer bo

Preview the exact graph diff before proposing:

hale dna apply team.batch --dry-run

+ position position:api/dev
+ mandate position:api/dev
+ position position:api/reviewer
+ mandate position:api/reviewer
+ holds position:api/dev ada
+ holds position:api/reviewer bo
6 line(s) added to the organization, 0 unchanged
nothing proposed (--dry-run)

Run hale dna apply team.batch (without --dry-run) to propose the batch, and ratify it with hale dna review changes approve. If the organization graph changes before the Board decides the Review in a way that invalidates any step, approving the Review refuses the entire batch atomically.

Complete Batch Step Vocabulary

Batch Statement	Effect on Organization Graph
`open <pos> [under <part>] \| <mandate>`	Opens `position:<pos>` and binds `<mandate>` to it.
`fill <pos> <holder>`	Assigns `<holder>` to `position:<pos>`.
`fill * <holder>`	Evaluated last: assigns `<holder>` to every position in the resulting graph that has a mandate and no holder.
`vacate <pos> <holder>`	Removes `<holder>` from `position:<pos>` while keeping the position open (also available standalone via `hale dna vacate <pos> <holder>`).
`practice <name> [for <pos>] \| <text>`	Proposes a practice (optionally bound to `<pos>`). Skips if already in force with identical text.
`law <name> \| <text>`	Proposes a practice as organizational law.
`idea <name> [for <pos>] \| <text>`	Proposes a knowledge node.
`retire-practice <name>`	Retires an active practice.
`assign <pos> reviews <target>` / `unassign …`	Adds or removes a `reviews` edge (e.g., `assign api/reviewer reviews contract:spec/todo.md`).
`merge <src-pos> into <dst-pos>`	Transfers all holders and `reviews` edges from `<src-pos>` to `<dst-pos>`, then closes `<src-pos>`.
`split <pos> into <pos-a> <pos-b>`	Replaces `<pos>` with `<pos-a>` and `<pos-b>`, copying the original mandate to both for subsequent amendment.
`close <pos>`	Closes `<pos>` and removes its holders and `reviews` edges (`position:board` can never be closed).
`expose seed:<name> as contract:<path>`	Declares that `seed:<name>` serves `contract:<path>`.
`depend seed:<name> on contract:<path>`	Declares that `seed:<name>` consumes `contract:<path>`.
`externalize seed:<name>`	Removes `seed:<name>` from the organism while retaining the organism’s dependency on its contract.
`internalize contract:<path> as seed:<name>`	Brings an external contract inside the organism as `seed:<name>`.

Nursery Packs (`hale dna pack`)

A pack is a parameterized batch template (<param> placeholders and optional ? lines that are omitted when their parameter is unset) stored in a nursery (a directory or Git repository containing a root nursery.toml index). The Hale toolchain embeds a built-in nursery containing standard packs (standard, founder, dev-team, etc.).

hale dna pack list
hale dna pack show dev-team --set part=api
hale dna pack apply dev-team --set part=api --set dev=ada --dry-run
hale dna pack apply dev-team --set part=api --set dev=ada
hale dna pack retire dev-team

Builtin standard pack: Proposes standard engineering practices as law (starting with structured logging via std::log) plus an upstream watch template for each external dependency (Upstream watches).
External nurseries (--from <dir|git-url[#rev]>): Git nurseries must be trusted by the Board before their packs can be applied (hale dna nursery add <url>, inspected via hale dna nursery list). Every pack Review records the pack name, digest, and nursery source.
Retiring a pack (hale dna pack retire <name>): Opens a single Review that reverses the most recent ratified adoption of <name> (closing opened positions, vacating filled seats, removing added review edges, and retiring practices that are still present).

A pack at the graft

Because hale habitat graft proposes initial positions (holes) as pending Reviews rather than immediately ratified nodes, a normal batch cannot fill position:board until holes is approved. Passing --with <pack> at graft time (or --on-holes to hale dna apply / hale dna pack apply) plans the batch on top of the pending hole Reviews:

hale habitat graft . --with founder --set founder=alice --as alice
hale dna review all approve --as alice

hale dna review all approve ratifies holes before changes, seating alice across the newly ratified positions in a single pass. If any underlying hole Review is rejected by the Board, the dependent pack Review is automatically refused as stale.

How the organization grows

Just as application code evolves through reviewed candidates, the organization’s own topology in dna/org/main.hl grows in response to operational signals:

Persistent Pressure (appendage_threshold = 3):
Terminal window
```
hale dna pressure raise ingest "the ingest worker lags behind the queue every evening"
hale dna pressure
```
When a single source raises pressure three times, the organization records appendage.proposed and notifies the Board (Senses and reflexes). When initiative: true (the default on dna::Dna), the organism automatically prepares an organization mutation adding a dedicated dna::Leader locus for that domain alongside the primary Leader in dna/org/main.hl, verifies it, records appendage.candidate, and submits it to the Board for review. Once applied and expressed, the observation window evaluates the declared fitness signals and records pressure.remeasured. (Set initiative: false on dna::Dna to log appendage.proposed without generating a candidate.)
Scheduled Optimize Pass (optimize-walk): Once the Board ratifies operating/optimize-cadence, the Leader runs a daily pass over structural signals in the record and proposes at most one small organizational refinement or logs org.reviewed (Schedules).

Keeping the toolchain’s part current

After upgrading the hale binary, update your project’s vendored runtime and lockfile:

hale dna upgrade

vendor/dna: <n> file(s) rewritten, <m> unchanged; hale.lock pins toolchain <version>, embedded dna <digest>. dna/ untouched.

What `hale dna upgrade` Updates vs. Preserves

Target	Behavior During `hale dna upgrade`
`vendor/dna/` & `hale.lock`	Re-materializes `vendor/dna/` from the current binary and updates `[dna] toolchain` in `hale.lock` and `.hale/dna/embedded.digest`.
`dna/org/workflows.hl`	Rewritten to the current baseline catalog. Any custom definitions found in an older `workflows.hl` are listed so you can move them to `dna/org/own_workflows.hl`.
Missing `dna/org/*.hl` files	Creates `models.hl`, `work.hl`, `charter.hl`, or `own_workflows.hl` if missing from an older project; never overwrites your existing edits in those files.
`dna/org/main.hl`	Updates only exact, unmodified lines produced by an older generator (tick loop, Board field, retired owners field); prints `note:` lines for any manual additions you may want to adopt.
Legacy checkout service files	Removes obsolete `dna/compose.yaml`, `dna/nats.conf`, `dna/nats.secrets.conf`, `dna/postgres.secrets`, and `dna/senses.yml` (allocations now live in the local habitat under `~/.local/share/hale/habitat/local/allocations/<id>/`) and provisions fresh NATS credentials into the vault.
Seeded practices & library	Proposes superseding Board Reviews for any seeded `design`, `operating`, or `using` practice whose text changed in the new toolchain, plus new `library` families.
Postgres memory schema	When `HALE_DNA_MEMORY_DSN_OWNER` is set, migrates the Postgres memory schema to the current toolchain version (`hale habitat migrate` migrates local habitat allocations).