Project-level policy document that captures the HiC's operating constraints, quality rules, and active charter for a repository. Compiled from interview answers and charter offering choices.
The tier a Charter Pack occupies, declared by the pack_level field in the pack's pack.yaml — one of built-in, org or project, in ascending precedence (ADR 2026-10-11-2). The level is no longer inferred from where a pack is wired in; a pack states its own level. The three level names have one authority, kernel.pack_tiers, and the tier token and the provenance/layer value share a single spelling, built-in (the former no-hyphen builtin provenance spelling is folded away). Loading refuses a pack whose declared level disagrees with where it is configured (PACK_LEVEL_MISMATCH), and a pack.yaml that omits the field (PACK_LEVEL_MISSING); for one release an org pack with no pack.yaml loads with a deprecation warning that names the file to add, before the refusal takes effect.
A guided question-and-answer process that walks the HiC through their project's preferences, constraints, and artifact selections. Answers are saved to answers.yaml and used to compile the charter.
The processor that takes the HiC's interview answers and their selected doctrine artifacts, and combines them into a finalized charter document and supporting governance files.
The result of checking the HiC's active charter against the charter offering — confirming that the referenced paradigms, directives, and tools actually exist and are compatible with each other.
The single activation filter applied by charter.activation.resolver.ActiveCharterService (the activation-aware wrapper). It enforces the project charter's per-kind activation state on a doctrine service's paradigms, procedures, and agent_profiles surfaces, so every profile-resolving path passes through one consistent filter rather than re-implementing activation logic. The factory charter.activation.active_charter_service_builder.build_active_charter_service is the single construction seam that routes callers through this chokepoint.
An available profile is any agent profile present in a layer of the charter offering (built-in, org pack, or project layer). An activated profile is an available profile that the project charter has explicitly turned on via activated_agent_profiles. Three-state semantics: when the key is absent, every available profile is activated; an explicit empty set activates none; an explicit set activates only the listed IDs. Since 4.0.0rc8 a profile listed in deactivated_agent_profiles (an Exclusion) is subtracted from that set unless an org pack requires it (Effective Set). Only activated profiles are directly selectable by default surfaces; available-but-not-activated profiles surface only under --all/--show-available.
The artifacts of one kind that are actually in force: the kind's allow state minus its Effective deny. The allow state is the activated_<kind> list when present, nothing for [], and, when the key is absent, every available artifact (for skill, the org-required ones plus the built-in defaults, empty today). The effective deny is the kind's Exclusions, matched by stem, declared id or DRG URN, minus the Required floor, so a deny never removes an org-required artifact. The governance selection overlay follows the same rule: selected_<kind> plus the required floor, minus the effective deny. Both are computed once, in charter.activation, from the Activation ledger (ADR 2026-10-19-1 Decision 2).
Deny-writer rule
Only four explicit choices change an exclusion list: charter deactivate <kind> <id> adds the id; charter activate <kind> <id> (also with --only) removes it; charter activate ... --cascade ... --include-deactivated removes the ids the walk reaches; charter activate --preset <name> --force removes the ids the preset lists. Presets without --force, the interview, org-required promotion, synthesis, mission-type seeding and every migration leave exclusions alone; a denied id they list stays out and is named in a warning. The activation-ledger write refuses (DenyListWriteRefused) any change to an exclusion list made without one of these choices.
An agent profile that is referenced via a specializes_from lineage edge but is not itself activated in the project charter. It acts as a shared-element store that concrete profiles inherit from; it is not directly selectable as a runtime persona. Resolving a profile whose lineage traverses an abstract base (an ancestor not in the activated set) yields a lineage warning rather than an error.