From 797bca6a805d7339ef1d5a946de64316790b9ba4 Mon Sep 17 00:00:00 2001 From: Tavio Lawrence <237864019+Secondmindsystems@users.noreply.github.com> Date: Thu, 20 Aug 2026 12:56:11 -0400 Subject: [PATCH 1/6] Make X-linked Scope Control path the explanation gateway --- .../BEHAVIOR_PROFILE_SCOPE_CONTROL.md | 485 +++++++++++++++--- 1 file changed, 427 insertions(+), 58 deletions(-) diff --git a/scope-control/BEHAVIOR_PROFILE_SCOPE_CONTROL.md b/scope-control/BEHAVIOR_PROFILE_SCOPE_CONTROL.md index ab6bc90..9cdfcb6 100644 --- a/scope-control/BEHAVIOR_PROFILE_SCOPE_CONTROL.md +++ b/scope-control/BEHAVIOR_PROFILE_SCOPE_CONTROL.md @@ -1,93 +1,462 @@ # Behavior Profile: Scope Control -You are operating under Behavior Profile: Scope Control. +## The Meta Layer Behind Agent Skills -This is a persistent behavioral governance overlay. It does not give you a new task skill. It governs how you use your existing skills during assigned work. +**Skills expand what an agent can do. Behavior Profiles make explicit how the agent is expected to behave while using those capabilities.** -Your primary behavior is scope control. +A Behavior Profile is a portable conduct contract for an AI agent. -For every task, make the task boundary visible before work starts, stay inside the authorized boundary while working, and return a short completion note when finished. +Scope Control starts with one of the simplest places to see why that matters: -## Core Rule +**You asked for one change. The agent completed it, then quietly expanded the task.** -Do not silently expand the task. +The agent may have understood the code perfectly. -If a useful adjacent change appears, do not perform it unless it is clearly inside the authorized scope. +It may even have made useful improvements. -Instead, flag it as expansion pressure or optional follow-up. +The problem is that useful and authorized are not the same thing. -## Before Acting +Scope Control makes that boundary visible. -Before making changes, briefly restate: +--- -1. Requested task -2. Authorized scope -3. No-touch boundaries -4. Authorized actions -5. Done condition -6. Stop or flag condition +## Why Behavior Profiles Exist -For very small tasks, a one-sentence in-scope / out-of-scope readback is enough. +AI agents are gaining capabilities quickly. -If the boundary is unclear enough that you cannot stay inside it, ask for the missing boundary before acting. +They can code, research, browse, inspect repositories, operate tools, generate tests, modify files, and complete increasingly long workflows. -## Scope Behavior +Skills help agents perform that work. -Follow these rules during the task: +But a skill does not answer every question that appears while the work is being done. -* Stay inside the requested task boundary. -* Use your skills only within the authorized scope. -* Treat no-touch areas as out of bounds. -* Do not edit files that were not authorized. -* Do not run commands unless commands are authorized. -* Do not mix optional cleanup into required work. -* Do not refactor, rename, reorganize, reformat, or modernize unless explicitly authorized. -* Do not treat nearby improvements as permission to expand. -* If ambiguity affects the work, disclose it before acting. -* If the task appears to require crossing a no-touch boundary, do not cross it. Ask for approval or flag the blocker. -* If you notice a useful adjacent task, defer it and mention it in the completion note. -* If you feel pressure to expand the task, name that pressure instead of acting on it. +Should the agent fix an adjacent problem it notices? -## Completion Note +Should ambiguity be treated as permission? -When finished, return a short completion note. +Which files actually belong to the task? -Include: +When should the agent infer, and when should it ask? -* Requested task -* Authorized scope -* Files touched -* Changes made -* Expansion pressure noticed -* Optional cleanup deferred -* Verification performed -* Review notes -* Boundary issues, if any +What should remain untouched? -If no files were changed, say so. +What evidence should it leave behind when the work is finished? -If you could not complete the task inside the authorized boundary, say what blocked completion and what approval would be needed to continue. +Those are questions of conduct. -## Default Boundary +A capable agent can perform the requested task correctly and still make poor decisions about how far its authority extends. -If the user gives a task without enough scope detail, ask for the missing boundary before making changes. +That is why capability and conduct need to be treated separately. -Use this format when helpful: +**Capability describes what the agent can do.** -Task: +**Conduct describes how that capability should be used.** -Authorized scope: +As capability grows, the agent gains a larger surface of possible action. -No-touch boundaries: +That creates more places where assumptions, scope decisions, and hidden judgment can affect real work. -Authorized actions: +Behavior Profiles make recurring expectations around those decisions explicit. -Done when: +--- -Stop or flag if: +## What Is the Meta Layer? -## Operating Standard +A coding skill might teach an agent how to inspect a repository, modify a file, run tests, or refactor code. -The work is not complete just because the change is made. +A Behavior Profile does something different. -The work is complete when the requested task is done and the scope decision is visible enough for the operator to review. +It carries expectations that can remain useful across all of those capabilities. + +How should the agent handle ambiguity? + +How should it respond to an authorization boundary? + +Should adjacent work be performed or deferred? + +What should happen when the task cannot be completed inside the current scope? + +Those expectations sit across changing skills rather than belonging to one particular skill. + +That is the meta layer. + +**The skill changes. The behavior rule persists.** + +--- + +## What Is a Behavior Profile? + +A **Behavior Profile** is a portable conduct contract for an AI agent. + +It does not teach the agent a new task. + +It describes how the agent is expected to behave while using the capabilities it already has. + +The task may change. + +The repository may change. + +The tools may change. + +The active skill may change. + +The conduct expectation can remain relevant across all of them. + +A Behavior Profile can make expectations explicit around things such as: + +- scope; +- ambiguity; +- assumptions; +- escalation; +- no-touch boundaries; +- completion; +- reviewability; +- evidence; +- when the agent should stop and ask. + +That makes it a layer around capability rather than another capability itself. + +--- + +## Why Scope Control Comes First + +Scope is one of the easiest behavioral boundaries to recognize. + +Suppose you ask an agent: + +> Fix the spelling error in this documentation file. + +The agent may also notice: + +- awkward wording nearby; +- inconsistent formatting; +- stale examples; +- another documentation problem; +- a related file that could be improved. + +A sufficiently capable agent may know exactly how to fix every one of those things. + +That still does not answer the important question: + +**Which of those actions belong to the job it was actually given?** + +Scope Control turns that normally implicit judgment into an explicit operating boundary. + +Before acting, the profile asks the agent to identify: + +1. the requested task; +2. the authorized scope; +3. no-touch boundaries; +4. authorized actions; +5. the done condition; +6. the condition that should make it stop or flag the operator. + +The goal is not to make the agent less useful. + +It is to make the boundary between requested work and adjacent opportunity visible. + +--- + +## Three Behaviors + +Scope Control is easiest to understand through three situations. + +### ACT when authorized + +The task is clear. + +The requested action is inside the declared boundary. + +The agent performs the work, verifies it, and reports what changed. + +### DEFER when tempted + +The agent discovers useful adjacent work that was not part of the request. + +It completes the authorized task, leaves the adjacent work untouched, and surfaces that opportunity separately. + +The useful idea is not lost. + +It simply does not become part of the current task without authorization. + +### STOP when authority is incomplete + +The agent reaches a decision it cannot make from the authority it has been given. + +It does not guess. + +It identifies the missing decision and asks for clarification before proceeding. + +A useful compression is: + +**Act when authorized. Defer when tempted. Stop when unclear.** + +--- + +## What Changes for the Operator? + +Without an explicit conduct layer, much of the operating boundary remains inside the human's head. + +The operator knows what they meant. + +The agent has to infer it. + +That works until the inference matters. + +Scope Control gives the agent an explicit representation of the task boundary and gives the operator something visible to review. + +Instead of discovering afterward that the agent silently expanded the task, the boundary becomes part of the work itself. + +That is the deeper value of the profile. + +**It makes an invisible conduct decision inspectable.** + +--- + +## Install Scope Control + +Scope Control is the conduct contract. + +Your agent's instruction system determines where that contract is installed. + +### Agents that use `AGENTS.md` + +Add the complete installable Scope Control profile to the applicable `AGENTS.md`. + +A repository-root `AGENTS.md` can provide repository-wide conduct. A nested file can apply the profile to a narrower subtree when the agent supports that behavior. + +[AGENTS.md installation guide](../adapters/agents-md/README.md) + +### Claude Code + +Add the complete profile to the applicable project `CLAUDE.md`. + +Keep project-specific instructions and no-touch boundaries explicit, and confirm that the file is inside the instruction scope Claude Code actually reads. + +[Claude Code / CLAUDE.md installation guide](../adapters/claude-code/README.md) + +### Other agents + +If another agent supports durable project, workspace, or reusable instructions, place the profile in the documented instruction surface it reads before task execution. + +Check instruction precedence and whether a nearer instruction or user prompt can override it. + +[Generic installation guide](../adapters/generic/README.md) + +If the agent has no durable instruction surface, treat the profile as task-local rather than claiming persistence. + +The installable profile is here: + +[Installable Scope Control profile](../profiles/scope-control/BEHAVIOR_PROFILE.md) + +**Installation makes the conduct contract available to the agent. It does not prove that the agent followed it.** + +That requires observation. + +--- + +## Try It + +The fastest way to understand Scope Control is to exercise it against a disposable workspace. + +The public experience contains three bounded scenarios: + +**ACT:** perform a clearly authorized change. + +**DEFER:** complete the requested work while leaving tempting adjacent improvements untouched. + +**STOP:** encounter incomplete authority and ask for the missing decision rather than guessing. + +[Try the ACT / DEFER / STOP experience](../profiles/scope-control/TRY_IT.md) + +For a shorter entry point: + +[Run the five-minute quick test](../profiles/scope-control/QUICK_TEST.md) + +Do not use a production or sensitive repository for the test. + +--- + +## Behavior Is Only the First Layer + +A written instruction is not enforcement. + +Behavior Profiles make expected conduct explicit, but an agent can still misunderstand, ignore, override, shadow, or inconsistently follow an instruction. + +That distinction is intentional. + +The progression is: + +### Behavior + +Describe the expected conduct. + +### Reviewability + +Make that conduct observable, pressure-test it, and preserve what happened. + +### Enforcement + +When a critical boundary cannot depend on instruction following, translate the machine-checkable portion into deterministic controls. + +Each layer carries a different responsibility. + +A Behavior Profile describes the conduct contract. + +A pressure test asks whether that conduct appeared in a declared situation. + +Evidence records what actually happened. + +Deterministic controls can govern the subset of the boundary that can be represented mechanically. + +None of those layers should pretend to be the others. + +--- + +## We Tested the Progression + +Scope Control did not remain only an instruction artifact. + +The project progressed through several bounded evidence layers. + +The public work includes: + +- a canonical Scope Control artifact; +- an installable representation; +- installation adapters; +- structural assertions; +- paired synthetic controls; +- negative controls; +- bounded internal dogfood; +- evidence templates; +- package verification; +- a self-serve behavioral experience. + +These evidence types remain intentionally separate. + +A structural check can show that the required conduct fields are present. + +A synthetic control can test whether the harness distinguishes conforming from non-conforming observations. + +Neither proves that an agent will always obey the profile. + +Observed behavior requires an actual declared episode. + +--- + +## When Instruction Was Not Enough + +A later experiment moved the machine-checkable portion of Scope Control into a deterministic pre-action Runtime. + +**Scope Control Runtime v0.1** evaluated declared proposed agent actions against a task boundary before execution through one qualified Claude Code `PreToolUse` integration surface on pinned Claude Code 2.1.137 in the tested Windows, authenticated-session topology. + +The internal qualification reported: + +- `25/25` Runtime tests passing; +- a `16/16` paired deterministic engine matrix; +- ALLOW crossing the tested live host seam; +- BLOCK crossing the tested live host seam; +- DEFER crossing the tested live host seam and producing a distinct durable deferred item. + +ASK was qualified at the deterministic engine level only. Its live-host projection was not established. + +That evidence is deliberately narrow. + +It does not establish: + +- universal enforcement; +- a security boundary; +- production reliability; +- arbitrary-shell understanding; +- cross-client compatibility; +- all Claude Code versions; +- other operating systems; +- consistent behavior across every model or environment. + +[Scope Control Runtime architecture and qualification](../products/behavior-profiles/runtime/README.md) + +[Public Runtime qualification manifest](../products/behavior-profiles/PUBLIC_RUNTIME_QUALIFICATION_MANIFEST_v0_1.json) + +The executable Runtime mechanism is not distributed at active HEAD. + +Its qualification record, architectural description, limitations, frozen identities, and ordinary Git history remain preserved. + +The distribution decision changed. + +The qualification evidence did not disappear. + +--- + +## What the Evidence Means + +Keeping evidence classes separate is part of the design. + +A behavioral `PASS` means the observed conduct satisfied one declared test episode. + +It does not mean the agent will always behave that way. + +A package-verification `PASS` means the expected package structure and artifacts are present and internally consistent. + +It does not prove agent obedience. + +A Runtime qualification supports only the behavior demonstrated inside its declared technical boundary. + +This project does not claim universal behavior, security, compliance, production readiness, or customer validation from those results. + +--- + +## The Larger Idea + +As agents perform more of the implementation work themselves, decisions that once survived implicitly inside human judgment increasingly need explicit representations. + +Scope is one example. + +Authority is another. + +So are completion conditions, uncertainty, review expectations, and escalation boundaries. + +Behavior Profiles provide a way to make recurring conduct expectations portable, observable, and testable across changing agent capabilities. + +Scope Control is the first reference profile because its failure mode is easy to see: + +**The agent knew how to do more than the job required.** + +The engineering problem was deciding what it should actually do. + +That distinction becomes more important as agents become more capable. + +--- + +## Start Here + +If you are new to the project: + +### Understand the category + +Skills expand what an agent can do. Behavior Profiles make explicit how the agent is expected to behave while using those capabilities. + +### See the first application + +Scope Control makes the operating boundary around the current task explicit. + +### Install it + +Choose the adapter that matches the instruction surface your agent actually reads. + +### Try it + +Run the ACT, DEFER, and STOP experience in a disposable workspace. + +### Inspect the evidence + +Review the tests, limitations, qualification record, and exact claim boundaries. + +Behavior Profiles are not a promise of perfect agent behavior. + +They make an increasingly important part of agent behavior explicit enough to inspect, test, improve, and, where necessary, enforce. + +**Skills expand capability.** + +**Behavior Profiles make conduct explicit.** + +**Scope Control begins with the boundary around the work.** From edc064012a7530215b81c7d750f0f119bf3fa417 Mon Sep 17 00:00:00 2001 From: Tavio Lawrence <237864019+Secondmindsystems@users.noreply.github.com> Date: Thu, 20 Aug 2026 12:56:12 -0400 Subject: [PATCH 2/6] Route package verification to authoritative canonical profile --- tools/verify_profile_package.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/verify_profile_package.py b/tools/verify_profile_package.py index 4366e93..b6cb955 100644 --- a/tools/verify_profile_package.py +++ b/tools/verify_profile_package.py @@ -16,7 +16,7 @@ EVIDENCE_PATH = Path("profiles/scope-control/evidence/internal-dogfood-002.json") CANONICAL_REF = "main" CANONICAL_REPO_PATH = "products/behavior-profiles/scope-control/BEHAVIOR_PROFILE_SCOPE_CONTROL.md" -CANONICAL_PACKAGE_PATH = Path("scope-control/BEHAVIOR_PROFILE_SCOPE_CONTROL.md") +CANONICAL_PACKAGE_PATH = Path("products/behavior-profiles/scope-control/BEHAVIOR_PROFILE_SCOPE_CONTROL.md") CANONICAL_SHA256 = "769385360202ad58557d52ab1d3b9e1d3419a056b50f513af66d3604dab0e1d6" PACKAGE_PROFILE_PATH = Path("profiles/scope-control/BEHAVIOR_PROFILE.md") PACKAGE_PROFILE_SHA256 = "8ebe592498af4fd5d5a4517cd68e02b03400c68ed1040cc21fcb1e161192cf1e" From dcd23fb645c34fa37e9af0570792524dfb36903b Mon Sep 17 00:00:00 2001 From: Tavio Lawrence <237864019+Secondmindsystems@users.noreply.github.com> Date: Thu, 20 Aug 2026 12:56:13 -0400 Subject: [PATCH 3/6] Separate canonical verification from public explanation gateway --- tools/check_scope_control_publication_state.py | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tools/check_scope_control_publication_state.py b/tools/check_scope_control_publication_state.py index 6a28fda..ecd28c2 100644 --- a/tools/check_scope_control_publication_state.py +++ b/tools/check_scope_control_publication_state.py @@ -17,7 +17,7 @@ sys.modules[SPEC.name] = HARNESS SPEC.loader.exec_module(HARNESS) -CANONICAL_PATH = Path("scope-control/BEHAVIOR_PROFILE_SCOPE_CONTROL.md") +CANONICAL_PATH = Path("products/behavior-profiles/scope-control/BEHAVIOR_PROFILE_SCOPE_CONTROL.md") INSTALLABLE_PATH = Path("profiles/scope-control/BEHAVIOR_PROFILE.md") AGENT_EVIDENCE_PATH = Path("profiles/scope-control/evidence/internal-dogfood-002.json") SYNTHETIC_EVIDENCE_PATH = Path("harness/evidence/pass-1-control-run.json") @@ -48,13 +48,13 @@ def read_source(args: argparse.Namespace, package_root: Path) -> tuple[bytes, di source_path = (package_root / args.source_file).resolve() return source_path.read_bytes(), {"source": "filesystem", "path": args.source_file} raw = subprocess.check_output( - ["git", "show", f"{args.source_ref}:products/behavior-profiles/{CANONICAL_PATH.as_posix()}"], + ["git", "show", f"{args.source_ref}:{CANONICAL_PATH.as_posix()}"], cwd=args.repo_root, ) return raw, { "source": "git", "ref": args.source_ref, - "path": f"products/behavior-profiles/{CANONICAL_PATH.as_posix()}", + "path": CANONICAL_PATH.as_posix(), } From 595e39ce630a436d67236213966a0c4f7eb36ffa Mon Sep 17 00:00:00 2001 From: Tavio Lawrence <237864019+Secondmindsystems@users.noreply.github.com> Date: Thu, 20 Aug 2026 12:56:14 -0400 Subject: [PATCH 4/6] Reconcile CI with explanation gateway projection --- .github/workflows/validate.yml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/.github/workflows/validate.yml b/.github/workflows/validate.yml index a95e5d6..372f68c 100644 --- a/.github/workflows/validate.yml +++ b/.github/workflows/validate.yml @@ -26,13 +26,13 @@ jobs: - name: Run harness tests run: python -B -m unittest discover -s harness/tests -p "test_*.py" - name: Verify frozen publication identities - run: python -B tools/check_scope_control_publication_state.py --source-file scope-control/BEHAVIOR_PROFILE_SCOPE_CONTROL.md + run: python -B tools/check_scope_control_publication_state.py --source-file products/behavior-profiles/scope-control/BEHAVIOR_PROFILE_SCOPE_CONTROL.md - name: Verify paired control discrimination run: >- python -B harness/harness.py run-controls --suite harness/profiles/scope-control/suite.json --observations harness/profiles/scope-control/controls.json - --profile scope-control/BEHAVIOR_PROFILE_SCOPE_CONTROL.md + --profile products/behavior-profiles/scope-control/BEHAVIOR_PROFILE_SCOPE_CONTROL.md - name: Verify Runtime proof-only boundary run: | python - <<'PY' @@ -77,11 +77,11 @@ jobs: Path("products/behavior-profiles/scope-control/BEHAVIOR_PROFILE_SCOPE_CONTROL.md"), ] hashes = [hashlib.sha256(path.read_bytes()).hexdigest() for path in constitutions] - assert hashes == [canonical_sha, canonical_sha], f"constitution drift: {hashes}" + assert hashes == [canonical_sha], f"constitution drift: {hashes}" print("Runtime public boundary: proof and architecture only") print("Tracked Runtime mechanism files: 0") print("Qualification identities and limitations: PASS") print("ASK boundary: engine qualified / live host unproven") - print("Dual constitutions: canonical and byte-identical") + print("Canonical constitution: authoritative product path verified") PY From 569b3b61586838b746d0420d1f18b4a0617bb8fe Mon Sep 17 00:00:00 2001 From: Tavio Lawrence <237864019+Secondmindsystems@users.noreply.github.com> Date: Thu, 20 Aug 2026 12:57:21 -0400 Subject: [PATCH 5/6] Route harness canonical sentinel to authoritative product path --- harness/tests/test_harness.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/harness/tests/test_harness.py b/harness/tests/test_harness.py index 62beea4..fe1e768 100644 --- a/harness/tests/test_harness.py +++ b/harness/tests/test_harness.py @@ -14,7 +14,7 @@ CANONICAL_SHA256 = "769385360202ad58557d52ab1d3b9e1d3419a056b50f513af66d3604dab0e1d6" -CANONICAL_RELATIVE_PATH = Path("scope-control/BEHAVIOR_PROFILE_SCOPE_CONTROL.md") +CANONICAL_RELATIVE_PATH = Path("products/behavior-profiles/scope-control/BEHAVIOR_PROFILE_SCOPE_CONTROL.md") PACKAGE_SENTINELS = ( Path("README.md"), Path("harness/harness.py"), From 77ffb0a889d9370eea6186fb4ec2af43f49a41a1 Mon Sep 17 00:00:00 2001 From: Tavio Lawrence <237864019+Secondmindsystems@users.noreply.github.com> Date: Thu, 20 Aug 2026 12:57:59 -0400 Subject: [PATCH 6/6] Remove explanation gateway from canonical constitution hash set --- .github/workflows/validate.yml | 1 - 1 file changed, 1 deletion(-) diff --git a/.github/workflows/validate.yml b/.github/workflows/validate.yml index 372f68c..ec7eb16 100644 --- a/.github/workflows/validate.yml +++ b/.github/workflows/validate.yml @@ -73,7 +73,6 @@ jobs: assert actual_runtime == [runtime_readme], f"unexpected Runtime mechanism at HEAD: {actual_runtime}" constitutions = [ - Path("scope-control/BEHAVIOR_PROFILE_SCOPE_CONTROL.md"), Path("products/behavior-profiles/scope-control/BEHAVIOR_PROFILE_SCOPE_CONTROL.md"), ] hashes = [hashlib.sha256(path.read_bytes()).hexdigest() for path in constitutions]