Kai Ase Siren
Skip to content

Role boundaries

A boundary is one behavior removed from several roles and allocated to exactly one owner. Use one when restating that allocation per charter would let the copies drift apart. A body every role declares is a roster-wide rule instead.

Why boundaries exist

Role skill bodies have a 1,200-word ceiling. Before boundaries, every role sharing an allocation restated it in its own charter, so shared policy competed with role-specific prose for one budget. Extraction freed 602 words across the Core Roster with no doctrine lost, and each side is bounded separately.

How a boundary differs from its neighbours

  • Personality - shared and eager too, but carries disposition, a color, and identity primitives, and never overrides a role obligation.
  • Method - progressive disclosure, owned by exactly one role, inactive until role and task both match.
  • Boundary - one behavior removed from several roles and allocated to exactly one owner.

Package layout

Declare the catalog entry in a library, then reference it from each role:

boundary "modify-live-backend" skill="boundary-modify-live-backend" owner="sysadmin-senior" summary="Senior Sysadmin changes running backend systems, other roles observe and hand the action over"
role "eng-platform" {
    skill "role-eng-platform"
    boundary "suggest-external-comms"
    personality "tenacious" "grounded"
}

Store each body beside the personality definitions:

libraries/kai-core/boundaries/01-modify-live-backend.kdl
libraries/kai-core/definitions/skills/boundary-modify-live-backend/SKILL.md

The catalog id, skill property, and frontmatter name must agree, so boundary modify-live-backend binds boundary-modify-live-backend. An unreferenced boundary fails loading.

Three states, not two

A role owns a boundary, defers it, or holds it within a scope. The third is a bounded grant rather than an absence, so it needs a declaration of its own: the limit text is the whole content, and a role that omits a boundary says nothing at all.

role "game-dev" {
    boundary "build-foundational-software" "seek-external-validation"
    boundary-scoped "modify-live-backend" scope="a local world you run yourself, never a hosted surface"
}

Scoping is not deferring, and the parser rejects a role that does both for one boundary. An owner may not scope its own boundary either, since it already receives the body by owning it and would be handed two contradictory sides.

The scoped side of the body sits between the own and defer sides, under ## If you hold this boundary within a scope. It is optional: a boundary nobody scopes needs no third section, which is what keeps packages authored before this axis loading unchanged. A role that scopes a boundary whose body lacks that section fails to load, so the grant can never arrive without its instructions.

What it buys the evaluation board

A boundary is scored as a pair, the in-half proving the rule fires and the out-half proving it does not fire on the neighbouring case that must still be served. A scoped grant fits neither half, so it earns its own pair: a within-scope case proving the grant works, and a beyond-scope case proving the limit holds. That moves the measured question from does the rule fire to does the grant hold its limits, and "acted, but exceeded the scope" is the failure a binary model cannot see.

The board writes that pair from scoped_boundaries, within-scope as the in-half, so in means one thing in all three states: acting on own territory.

Selection and delivery

Agent Compose selects a boundary with every role that declares it and with its owner. The identity card lists them under Boundaries, marking each as owned or deferred, and repeats them in Active doctrine so the agent loads them before acting. Sharing one body is expected, not a collision.

The bundle manifest records the selected boundaries, the decision trace carries one boundary:<id> entry per role, and bundle verification fails when the manifest and trace disagree.

Evaluation

Packs carry boundary bodies in a boundaries block beside the briefing, so doctrine that left a charter still reaches the driver rather than scoring an incomplete role. Both sides receive the body, so both owe its case. Changing a body moves the pack digest for every role on either side, retiring those results until an independently reviewed re-run.

Core Roster boundaries

Each slug names the behavior that moves. Every boundary reaches all thirteen seats and exactly one owns it, so a missing seat is a defect. The rest split per boundary. Archiving a seat does not drop it from a boundary, so analyst, psych and reporter still appear below. Sysadmin split into senior-sysadmin and junior-sysadmin on 2026-09-17 (#500); access-sysadmin joins them as a color twin with scoped permission-config and single-owner workstation grants. Manager shapes tracker records under its own charter and defers all four boundaries. Deferring is delegation: the owner is the specialist, so handing work over is the ordinary way it gets done rather than a permission request, every defer section opens by saying so, and the identity card labels that side "you hand this to its specialist".

Two boundaries were deleted on 2026-09-15 with the seats that owned them: hold-emotional-weight, owned by psych, and study-an-unmet-party, owned by reporter. Neither behavior is allocated now, so no seat defers it and no seat owns it.

  • modify-live-backend, owner senior-sysadmin - scoped for platform, gamedev, analyst, and access-sysadmin, who run CI and local environments, run a world they launched themselves, remediate the specific control failure they already wrote up, and converge agent config on single-owner workstations, respectively. Deferred by advocate, director, frontend, science, psych, reporter, junior-sysadmin, and manager.
  • suggest-external-comms, owner advocate - scoped for frontend and gamedev, who write the words inside the artifact they own. Deferred by access-sysadmin, analyst, director, platform, psych, reporter, science, senior-sysadmin, junior-sysadmin, and manager.
  • seek-external-validation, owner director - scoped for advocate, platform, and analyst, who read their audience, audit a candidate dependency, and reach the regime the system under assessment answers to. Deferred by access-sysadmin, frontend, gamedev, psych, reporter, science, senior-sysadmin, junior-sysadmin, and manager.
  • build-foundational-software, owner platform - scoped for senior-sysadmin, junior-sysadmin, science, access-sysadmin, frontend, and gamedev, who write estate configuration, measurement instruments, shared agent permission values, and the whole of a surface or game only they work on, dependencies included, inside their named limits. Deferred by advocate, analyst, director, psych, reporter, and manager.

See also