Skip to content
CBE / Capability design
Capability Boundary Expander

Complete the responsibility.
Preserve the boundary.

CBE asks what an already defined capability still needs to perform its own responsibility. It separates legitimate internal expansion from work owned by neighboring capabilities, then makes the boundary and handoffs explicit.

One bounded analysis

Expand from a demonstrated gap

A useful nearby feature is not automatically part of the target's responsibility. Every candidate must trace to an internal gap and survive relevance, ownership and identity checks.

Start with

  • A named target and its purpose.
  • Current responsibilities and a locked responsibility invariant.
  • Known peers, constraints and supporting evidence.

Unknown ownership stays unresolved until evidence or an architectural decision can settle it.

Return

  • Internal gaps and classified candidates.
  • Retained responsibilities and their boundaries.
  • Explicit handoff contracts and rejected scope.
  • Residual uncertainty and verification findings.
  1. Lock the target's responsibility and normalize what it already owns.
  2. Find internal gaps; derive candidate extensions from those gaps.
  3. Check target relevance and substantive overlap with peers.
  4. Classify, split mixed responsibilities and record handoffs.
  5. Audit completeness, preserved responsibilities, uncertainty and target identity.
Four verdicts, four different consequences
VerdictUse whenDesign result
KEEPThe responsibility is needed and belongs to the target.Add it to the target's design.
SPLITThe candidate mixes target-owned work with portions that belong elsewhere or are unnecessary.Separate meaningful parts and classify each: KEEP the target portion, DELEGATE peer-owned work or REJECT unnecessary scope.
DELEGATEThe target needs the result, but a peer owns the operation.Define a handoff and expected return.
REJECTThe candidate does not close an internal gap or changes target identity.Record the reason for excluding it.

UNRESOLVED records insufficient evidence or an ownership question. It is not a fifth acceptance verdict. Using a peer's output does not mean owning that peer's operation.

Shared example with CBE-IX

A document ingestion pipeline

Responsibility invariant: accept documents and produce normalized ingestible records. Preserve the existing steps: accept, extract, normalize and submit downstream. The Semantic Indexer owns embeddings; the Retention Policy Service owns retention decisions; the Malware Scanner owns malicious-content detection.

Candidate decisions under these declared boundaries
Gap / candidateDecisionReason or handoff
Accepted formats are not distinguished: detect document format.KEEPFormat detection supports the pipeline's own extraction step.
An accepted format needs an extraction handler: select its parser.KEEPUse the supplied format-to-parser mapping; the pipeline owns handler selection.
Repeated submissions are not distinguished: perform ingestion-level duplicate detection.KEEPCompare the supplied document identifier with the provided ingestion record set. Record new or duplicate and apply the supplied submission rule.
Submission needs a scanner outcome: coordinate the safety gate.KEEPRequest a scan, preserve the returned outcome and hold downstream submission unless the supplied gate condition is met.
Determine whether document content is malicious: implement the malware detection algorithm.DELEGATEThe Malware Scanner owns malicious-content detection. Coordinating the handoff does not transfer its algorithm to ingestion.
Downstream search needs vectors: generate embeddings.DELEGATESend normalized content to the Semantic Indexer; consume its return.
Records need retention metadata: determine policy and attach classification.SPLITDELEGATE policy decisions; KEEP attaching the returned classification.
Add a conversational assistant for readers.REJECTNo demonstrated gap in ingestion requires a reader assistant.
Add regional access decisions; ownership is not supplied.UNRESOLVEDClarify the responsibility boundary before assigning a verdict.

Retained boundary

Owns: attaching the supplied retention classification to a normalized record.

Does not own: defining retention policy or deciding how long records must be retained.

Input: normalized record plus a classification returned by the policy service.

Output: enriched record, or an explicit unresolved classification.

Handoff contract

Trigger: a record needs retention classification.

Destination: Retention Policy Service.

Target supplies: the agreed record metadata.

Destination owns: the policy decision.

Expected return: classification or unresolved result. The pipeline attaches the return or preserves the unresolved state.

Malware Scanner handoff

Trigger: an accepted document needs a safety result before downstream submission.

Destination: Malware Scanner.

Target supplies: the document and its correlation identifier.

Destination owns: the malware detection algorithm.

Expected return in this fixture: clear, flagged or unavailable, tied to that identifier.

Target behavior after return: preserve the result. Only clear permits the safety gate to release submission; flagged or unavailable holds it. A clear result is the scanner's answer, not proof of universal safety.

Bounded evidence for the walkthrough

The fixture supplies document identifiers and an ingestion record set. Its submission rule allows a new identifier to proceed to the safety gate; a duplicate is recorded and held without rewriting the prior record. Ingestion owns comparing these inputs and recording the outcome; it does not invent a retention decision.

The safety gate owns requesting and consuming a scanner result. It does not inspect content to decide whether it is malicious. Duplicate outcomes and the three supplied scanner returns are reviewed in I1; their handling is locally exhausted in this finite fixture.

The identifier comparison, supplied duplicate rule and clear/flagged/unavailable return contract are teaching assumptions added to the source's responsibility example. They are not claimed as prescribed implementation details.

This bounded example also retains parser selection alongside format detection. It is the I1 snapshot replayed in CBE-IX. The next pass examines previously unspecified ambiguous parser matches and conflicting classification returns; it does not rediscover parser selection or the unresolved-classification state.

The candidate verdict changes the design representation. It does not edit the pipeline, call the peer or authorize deployment.

Six verdicts for the whole CBE analysis

KEEP, SPLIT, DELEGATE and REJECT classify individual candidates. The source's output contract, section L, requires one final verdict for the complete analysis, alongside its verification audit and residual uncertainty.

EXPANSION_VALID
The bounded expansion is valid under the recorded audit and evidence.
EXPANSION_VALID_WITH_HANDOFFS
The valid result retains explicit handoffs to other owners.
EXPANSION_REQUIRES_SPLIT
The proposed responsibility grouping requires explicit separation.
BOUNDARY_UNRESOLVED
A responsibility boundary remains unresolved.
TARGET_IDENTITY_DRIFT
The expanded design no longer preserves the target identity.
INSUFFICIENT_INFORMATION
The available target or responsibility evidence is insufficient.

The source requires the V1-V14 audit. A FAIL on V1 (responsibility invariant), V5 (KEEP owning a peer responsibility) or V10 (target identity) makes the expansion unacceptable as-is.

When unresolved ownership prevents further iteration without peer takeover, CBE's BOUNDARY_UNRESOLVED corresponds to CBE-IX's BLOCKED_BY_BOUNDARY_DECISION. An unresolved candidate alone does not automatically establish that iterative blocker.

The classification lab below assesses one candidate at a time. It does not calculate or certify a final CBE verdict for an entire analysis.

Synthetic practice

Classify without absorbing a peer

Choose a candidate from the ingestion example, make a prediction and inspect the curated explanation. This exercise uses declared boundaries; it does not infer ownership from arbitrary text.

Continue with the same target in the CBE-IX iteration lab.

Where CBE fits

Discover before expanding

Capability-Gap and CSR establish what exists and where a need is already covered. CBE then examines the selected target's internal completeness. SORR can resolve ambiguous identities and responsibility claims.

Control the analysis

Dialogue Lifecycle controls transitions. 5PP Variation A structures the scoped work and audit. AICS can represent the resulting requirements and decisions. Analysis authorization and implementation authorization remain separate.

When to use CBE-IX

Use CBE-IX when an accepted extension may expose further legitimate internal gaps. It adds an iteration ledger, a frontier of unprocessed work and explicit convergence checks.

Source basis and limits

Derived from the author-provided Capability Boundary Expander - AI Execution Prompt, updated 24 August 2026. The ingestion example adapts its Example 2; the reader-assistant and unknown-owner cases are additional teaching examples.

Source mapping and reproducibility notes identify the exact supplied source snapshot. The profile explains a design method; the lab demonstrates curated cases and does not establish general semantic correctness, runtime availability or measured effectiveness.