markspace 0.2.0b0__tar.gz → 0.3.0b0__tar.gz

markspace-0.3.0b0/.gitattributes

@@ -0,0 +1,5 @@
+**/*.jsonl filter=lfs diff=lfs merge=lfs -text
+**/*.png filter=lfs diff=lfs merge=lfs -text
+*.jsonl filter=lfs diff=lfs merge=lfs -text
+experiments/stress_test/results_*/*.log filter=lfs diff=lfs merge=lfs -text
+experiments/stress_test/results_*/*.json filter=lfs diff=lfs merge=lfs -text

{markspace-0.2.0b0 → markspace-0.3.0b0}/CITATION.cff

@@ -2,8 +2,8 @@ cff-version: 1.2.0
 title: markspace
 message: "If you use this work, please cite it using the metadata below."
 type: software
-version: 0.2.0-beta
-date-released: 2026-05-08
+version: 0.3.0-beta
+date-released: 2026-11-02
 doi: 10.5281/zenodo.18990235
 url: https://github.com/opinionated-systems/markspace
 abstract: >
@@ -13,9 +13,10 @@ abstract: >
   boundary enforces identity, scope, and conflict resolution outside
   the agents, so safety guarantees hold independent of agent behavior.
   The protocol defines five mark types encoding distinct epistemic
-  roles, three visibility levels, three conflict policies, and
+  roles, three visibility levels, three conflict policies, conflict
+  resolution across a scope tree, leases with fencing tokens, and
   trust-weighted decay. The included Python package is a reference
-  implementation used to verify 66 formal properties experimentally.
+  implementation used to verify 76 formal properties experimentally.
 authors:
   - family-names: Loose
     given-names: Andre

{markspace-0.2.0b0 → markspace-0.3.0b0}/PKG-INFO

@@ -1,6 +1,6 @@
-Metadata-Version: 2.4
+Metadata-Version: 2.5
 Name: markspace
-Version: 0.2.0b0
+Version: 0.3.0-beta
 Summary: Environment-mediated coordination protocol for LLM agent fleets
 Project-URL: Homepage, https://github.com/opinionated-systems/markspace
 Project-URL: Repository, https://github.com/opinionated-systems/markspace
@@ -41,7 +41,7 @@ Description-Content-Type: text/markdown
 
 If you're coordinating multiple LLM agents, you've likely hit some of these:
 
-- **Prompt injection exposure** - agent identity and permissions are controlled by the LLM, so a compromised prompt can escalate privileges or impersonate other agents
+- **Prompt injection exposure** - agent identity and permissions are controlled by the LLM, so a [compromised prompt](https://role-confusion.github.io/) can escalate privileges or impersonate other agents
 - **Implicit permissions** - you find out what an agent shouldn't have done after it already did it
 - **Blind trust** - no standard way to distinguish your fleet's data from API responses or crawled content
 - **Context drift** - long-running agents lose track of what happened 200 steps ago and repeat or contradict earlier actions
@@ -51,7 +51,7 @@ If you're coordinating multiple LLM agents, you've likely hit some of these:
 
 Coordination guarantees should hold independent of agent behavior. Markspace is a [coordination protocol](docs/framework.md) for agent fleets built on [stigmergy](https://en.wikipedia.org/wiki/Stigmergy) - a mechanism by which biological systems coordinate at scale. Agents leave traces in a shared environment rather than messaging each other. A deterministic guard layer at the environment boundary enforces identity, scope, and conflict resolution. These constraints live in infrastructure the agent cannot influence. Coordination emerges without being configured; the fleet adapts as the world changes. Over time, the environment becomes a model of the world the agents operate in.
 
-The protocol defines five mark types, three visibility levels, three conflict policies, trust-weighted decay, and [70 formal properties](docs/spec.md). The included Python package is a reference implementation used to verify those properties experimentally.
+The protocol defines five mark types, three visibility levels, three conflict policies, conflict resolution across a scope tree, leases with fencing tokens, trust-weighted decay, and [76 formal properties](docs/spec.md). The included Python package is a reference implementation used to verify those properties experimentally.
 
 ## Motivation
 
@@ -86,19 +86,19 @@ Each mark type encodes a different epistemic role - a plan, a fact, a belief, a
 - **Warning**: "X is no longer valid" (spikes then decays)
 - **Need**: "I need a human decision on X" (persists until resolved)
 
-**Three visibility levels:** OPEN (full access), PROTECTED (structure visible, content redacted), CLASSIFIED (invisible to unauthorized agents).
+**Three visibility levels:** OPEN (full access), PROTECTED (structure visible, content redacted), CLASSIFIED (invisible to unauthorized agents). Each mark keeps its own scope's level, also when it is read through a parent scope, delivered by a subscription, or named in a guard decision.
 
-**Three conflict policies:** HIGHEST_CONFIDENCE (priority wins), FIRST_WRITER (first claim wins), YIELD_ALL (escalate to principal via need marks).
+**Three conflict policies:** HIGHEST_CONFIDENCE (priority wins), FIRST_WRITER (first claim wins), YIELD_ALL (escalate to principal via need marks). Across a scope tree, intents on one resource compete with intents in ancestor and descendant scopes, not in sibling scopes: the outer scope's intent wins, and inside one scope the scope's policy decides.
 
 **Trust weighting:** Marks carry a source tag (fleet, external verified, external unverified). Trust weights attenuate effective strength. Fleet marks dominate external ones, and unverified sources are discounted further. Weights are configurable per deployment.
 
 **Decay:** Coordination is a dynamical process - the goal is stability against continuous change, not a fixed solution reached once. Observations and warnings lose strength over configurable half-lives. Intent marks expire after TTL. Action marks are permanent. Stale information fades without explicit cleanup.
 
-Full protocol design in [`framework.md`](docs/framework.md). Formal specification (70 properties, conformance checklist) in [`spec.md`](docs/spec.md).
+Full protocol design in [`framework.md`](docs/framework.md). Formal specification (76 properties, conformance checklist) in [`spec.md`](docs/spec.md).
 
 ## Composition and isolation
 
-Blocking what a general-purpose agent shouldn't do requires anticipating every failure mode in advance. Composition takes the opposite approach: each agent declares what it can read and write in a manifest, and the guard rejects everything else. Capabilities you didn't grant don't exist.
+Blocking what a general-purpose agent shouldn't do requires anticipating every failure mode in advance. Composition takes the opposite approach: each agent's principal declares what the agent can read and write in a manifest, and the guard rejects everything else. Capabilities you didn't grant don't exist.
 
 Watch/subscribe lets agents activate when matching marks appear, forming pipelines without a central orchestrator. Agents can be added, removed, or replaced independently, and need marks let them escalate rather than grow to handle edge cases. The manifest interface is model-agnostic - each agent can run a different backend (cloud API, local open-weights model, or deterministic code), and sensitive scopes can run entirely on-premise.
 
@@ -130,15 +130,18 @@ The reference implementation and experiments verify that the protocol's properti
 <p align="center"><img src="experiments/trials/results/scaling_proportional/gpt-oss-120b/n_500/stress_test.gif" alt="525-agent stress test visualization"/></p>
 <p align="center"><sub>525 agents (105 per department, 25 adversarial) coordinating across 7 resource types over 10 simulated rounds. Model: <a href="https://fireworks.ai/models/fireworks/gpt-oss-120b">OpenAI gpt-oss-120b</a> via Fireworks. Left: agent activity by department. Center: marks accumulating in the shared space. Right: per-resource contention.</sub></p>
 
-**Unit tests (325):**
+**Unit tests (563):**
 
 - **Core mark operations** - algebra, immutability, uniqueness, ordering
 - **Protocol mechanics** - decay functions, trust weighting, conflict resolution, deferred resolution
-- **Guard enforcement** - scope visibility, trust source enforcement, tool failure handling
+- **Guard enforcement** - scope visibility (also through parent scopes, subscriptions and guard decisions), trust source enforcement, tool failure handling
+- **Conflicts across scope trees** - outer scope first, per-intent competing sets, deferred boundaries, leases and fencing tokens, equal-time intents in write order
 - **Composition** - agent manifest properties, scheduling
 - **Robustness** - garbage collection, thread safety under concurrent access
 - **Property-based ([Hypothesis](https://hypothesis.readthedocs.io/))** - randomized inputs, stateful scheduler fuzzing (register/unregister/update/tick sequences)
 - **Observability and cost controls** - telemetry sink non-interference, budget tracking accuracy, rate limit enforcement, fleet caps
+- **LLM client and stress-test pacing** - Retry-After handling, cached and reasoning token accounting, arrival-ordered pacing under rate limits (real threads)
+- **Stress-test safety metrics** - double bookings counted from the guard's decisions, recovered bookings apart, scope violations checked on every mark the harness hands an agent
 
 **[Stress test:](experiments/stress_test/analysis.md)** AI personal assistants for a simulated office - one per employee, plus adversarial agents that attempt to breach scope boundaries. No central scheduler, all coordination through the shared mark space. The scenario exercises 7 resource types across natural permission boundaries:
 
@@ -152,17 +155,17 @@ The reference implementation and experiments verify that the protocol's properti
 
 Department heads book with elevated priority. External system agents (parking bot, building ops) publish low-trust observations and warnings that decay over configurable half-lives. Adversarial agents with normal permissions but adversarial prompts attempt cross-department bookings and warning injection. All five mark types, all three conflict policies, and all three visibility levels produce non-trivial output in a single trial.
 
-Scenario design in [`design.md`](experiments/stress_test/design.md). Detailed analysis of resource allocation, agent behavior, temporal dynamics, and token economics in the [stress test writeup](experiments/stress_test/analysis.md).
+Scenario design in [`design.md`](experiments/stress_test/design.md). Detailed analysis of resource allocation, agent behavior, temporal dynamics, and token economics in the [stress test writeup](experiments/stress_test/analysis.md). A re-run on DeepSeek V4.1 Flash 1017 with a 2048-token thinking budget (one run, 2026-11-01) allowed no resource twice in one round and denied every cross-department write, with a mean manifest completion of 64.5% across departments against 58.8% for gpt-oss-120b; the two runs also differ in pacing and harness version ([section 9](experiments/stress_test/analysis.md#9-re-run-on-deepseek-v41-flash-1017)).
 
 **[Trial experiments:](experiments/trials/analysis.md)** 21 runs of the same scenario across 2 models - [OpenAI gpt-oss-120b](https://fireworks.ai/models/fireworks/gpt-oss-120b) (via Fireworks) and [Mercury 2](https://www.inceptionlabs.ai/blog/introducing-mercury-2), a diffusion-based LLM (via Inception AI). Agent counts from 105 (5 adversarial) to 1,050 (50 adversarial), 4,010 agent instances total.
 
-- **Adversarial** - agents with normal permissions but adversarial prompts attempt three attack modes (confidence manipulation, resource flooding, prompt injection). Zero safety violations on both models
-- **Safety** - zero double bookings and zero scope violations across all 21 runs
+- **Adversarial** - agents with normal permissions but adversarial prompts attempt three attack modes (confidence manipulation, resource flooding, prompt injection). No double booking found and every cross-department write denied, on both models
+- **Safety** - no resource allowed twice in one round, no lunch window over capacity, and every cross-department write denied, in all 21 runs (checked from their stored steps; [read leaks were not measured](experiments/trials/analysis.md#6-cross-experiment-safety))
 - **Repeatability** - 64.7% +/- 0.8% completion on gpt-oss-120b, 66.2% +/- 1.6% on mercury-2 (5 seeds each)
-- **Scaling** - up to 1,050 agents with proportionally scaled resources: per-agent step count nearly flat (1.2x at 10x scale), safety invariants hold at every scale point
+- **Scaling** - up to 1,050 agents with proportionally scaled resources: per-agent step count nearly flat (1.2x at 10x scale), no double booking found at any scale point
 - **Resource contention** - 5x more agents competing for the same resources: completion drops to 13.3% from resource scarcity, not protocol failure
 
-**[Defense stack trials:](experiments/trials/results/defense/analysis.md)** 6 attack modes (rate spike, type shift, privilege escalation, probe evasion, slow drift, combined) against the static enforcement layer + statistical envelope + diagnostic probe. 150 rounds, 105 agents per trial (5 adversarial). Zero safety violations across all attack modes. Full analysis in the [defense writeup](experiments/trials/results/defense/analysis.md).
+**[Defense stack trials:](experiments/trials/results/defense/analysis.md)** 6 attack modes (rate spike, type shift, privilege escalation, probe evasion, slow drift, combined) against the static enforcement layer + statistical envelope + diagnostic probe. 150 rounds, 105 agents per trial (5 adversarial). No double booking found across all attack modes (from the stored steps). Full analysis in the [defense writeup](experiments/trials/results/defense/analysis.md).
 
 **[Comparison experiment:](experiments/comparison/analysis.md)** Markspace vs a message-passing framework ([Microsoft Agent Framework](https://github.com/microsoft/agent-framework)) on a shared resource booking scenario. 10 agents, 12 slots, 10 seeds per arm.
 
@@ -181,7 +184,7 @@ The `markspace` package is a Python 3.11+ reference implementation. The protocol
 
 ```bash
 poetry install    # core package
-pytest            # 325 tests, no API key needed
+pytest            # 563 tests, no API key needed
 ```
 
 ### Use the protocol
@@ -268,7 +271,7 @@ See [`experiments/guide.md`](experiments/guide.md) for CLI reference and cost es
 ## Documentation
 
 - [`docs/framework.md`](docs/framework.md) - protocol design, biological foundations, composition, architecture, failure analysis
-- [`docs/spec.md`](docs/spec.md) - formal specification (70 properties, conformance checklist)
+- [`docs/spec.md`](docs/spec.md) - formal specification (76 properties, conformance checklist)
 - [`experiments/guide.md`](experiments/guide.md) - running experiments (setup, CLI reference, analysis, costs)
 - [`experiments/validation/`](experiments/validation/analysis.md) - safety, visibility, concurrency, scaling
 - [`experiments/stress_test/`](experiments/stress_test/) - 105-agent stress test ([design](experiments/stress_test/design.md), [analysis](experiments/stress_test/analysis.md))
@@ -294,7 +297,7 @@ Most users interact with `core.py` (types), `guard.py` (enforcement), and `space
 | [`telemetry.py`](markspace/telemetry.py) | Optional. OpenTelemetry-compatible metrics, structured logs, and trace context. |
 | [`compose.py`](markspace/compose.py) | Composition validation. Pipeline and manifest-permission checks. Stateless. |
 | [`schedule.py`](markspace/schedule.py) | Manifest-based scheduling with optional pre-activation budget checks. |
-| [`llm.py`](markspace/llm.py) | Provider-agnostic LLM client (OpenAI-compatible). |
+| [`llm.py`](markspace/llm.py) | Provider-agnostic LLM client (OpenAI-compatible), with `reasoning_effort`, cached and reasoning token accounting, and an optional per-request pacing hook (`RequestPacer`). |
 | [`models.py`](markspace/models.py) | Model registry. |
 
 ## Limitations

{markspace-0.2.0b0 → markspace-0.3.0b0}/README.md

@@ -6,7 +6,7 @@
 
 If you're coordinating multiple LLM agents, you've likely hit some of these:
 
-- **Prompt injection exposure** - agent identity and permissions are controlled by the LLM, so a compromised prompt can escalate privileges or impersonate other agents
+- **Prompt injection exposure** - agent identity and permissions are controlled by the LLM, so a [compromised prompt](https://role-confusion.github.io/) can escalate privileges or impersonate other agents
 - **Implicit permissions** - you find out what an agent shouldn't have done after it already did it
 - **Blind trust** - no standard way to distinguish your fleet's data from API responses or crawled content
 - **Context drift** - long-running agents lose track of what happened 200 steps ago and repeat or contradict earlier actions
@@ -16,7 +16,7 @@ If you're coordinating multiple LLM agents, you've likely hit some of these:
 
 Coordination guarantees should hold independent of agent behavior. Markspace is a [coordination protocol](docs/framework.md) for agent fleets built on [stigmergy](https://en.wikipedia.org/wiki/Stigmergy) - a mechanism by which biological systems coordinate at scale. Agents leave traces in a shared environment rather than messaging each other. A deterministic guard layer at the environment boundary enforces identity, scope, and conflict resolution. These constraints live in infrastructure the agent cannot influence. Coordination emerges without being configured; the fleet adapts as the world changes. Over time, the environment becomes a model of the world the agents operate in.
 
-The protocol defines five mark types, three visibility levels, three conflict policies, trust-weighted decay, and [70 formal properties](docs/spec.md). The included Python package is a reference implementation used to verify those properties experimentally.
+The protocol defines five mark types, three visibility levels, three conflict policies, conflict resolution across a scope tree, leases with fencing tokens, trust-weighted decay, and [76 formal properties](docs/spec.md). The included Python package is a reference implementation used to verify those properties experimentally.
 
 ## Motivation
 
@@ -51,19 +51,19 @@ Each mark type encodes a different epistemic role - a plan, a fact, a belief, a
 - **Warning**: "X is no longer valid" (spikes then decays)
 - **Need**: "I need a human decision on X" (persists until resolved)
 
-**Three visibility levels:** OPEN (full access), PROTECTED (structure visible, content redacted), CLASSIFIED (invisible to unauthorized agents).
+**Three visibility levels:** OPEN (full access), PROTECTED (structure visible, content redacted), CLASSIFIED (invisible to unauthorized agents). Each mark keeps its own scope's level, also when it is read through a parent scope, delivered by a subscription, or named in a guard decision.
 
-**Three conflict policies:** HIGHEST_CONFIDENCE (priority wins), FIRST_WRITER (first claim wins), YIELD_ALL (escalate to principal via need marks).
+**Three conflict policies:** HIGHEST_CONFIDENCE (priority wins), FIRST_WRITER (first claim wins), YIELD_ALL (escalate to principal via need marks). Across a scope tree, intents on one resource compete with intents in ancestor and descendant scopes, not in sibling scopes: the outer scope's intent wins, and inside one scope the scope's policy decides.
 
 **Trust weighting:** Marks carry a source tag (fleet, external verified, external unverified). Trust weights attenuate effective strength. Fleet marks dominate external ones, and unverified sources are discounted further. Weights are configurable per deployment.
 
 **Decay:** Coordination is a dynamical process - the goal is stability against continuous change, not a fixed solution reached once. Observations and warnings lose strength over configurable half-lives. Intent marks expire after TTL. Action marks are permanent. Stale information fades without explicit cleanup.
 
-Full protocol design in [`framework.md`](docs/framework.md). Formal specification (70 properties, conformance checklist) in [`spec.md`](docs/spec.md).
+Full protocol design in [`framework.md`](docs/framework.md). Formal specification (76 properties, conformance checklist) in [`spec.md`](docs/spec.md).
 
 ## Composition and isolation
 
-Blocking what a general-purpose agent shouldn't do requires anticipating every failure mode in advance. Composition takes the opposite approach: each agent declares what it can read and write in a manifest, and the guard rejects everything else. Capabilities you didn't grant don't exist.
+Blocking what a general-purpose agent shouldn't do requires anticipating every failure mode in advance. Composition takes the opposite approach: each agent's principal declares what the agent can read and write in a manifest, and the guard rejects everything else. Capabilities you didn't grant don't exist.
 
 Watch/subscribe lets agents activate when matching marks appear, forming pipelines without a central orchestrator. Agents can be added, removed, or replaced independently, and need marks let them escalate rather than grow to handle edge cases. The manifest interface is model-agnostic - each agent can run a different backend (cloud API, local open-weights model, or deterministic code), and sensitive scopes can run entirely on-premise.
 
@@ -95,15 +95,18 @@ The reference implementation and experiments verify that the protocol's properti
 <p align="center"><img src="experiments/trials/results/scaling_proportional/gpt-oss-120b/n_500/stress_test.gif" alt="525-agent stress test visualization"/></p>
 <p align="center"><sub>525 agents (105 per department, 25 adversarial) coordinating across 7 resource types over 10 simulated rounds. Model: <a href="https://fireworks.ai/models/fireworks/gpt-oss-120b">OpenAI gpt-oss-120b</a> via Fireworks. Left: agent activity by department. Center: marks accumulating in the shared space. Right: per-resource contention.</sub></p>
 
-**Unit tests (325):**
+**Unit tests (563):**
 
 - **Core mark operations** - algebra, immutability, uniqueness, ordering
 - **Protocol mechanics** - decay functions, trust weighting, conflict resolution, deferred resolution
-- **Guard enforcement** - scope visibility, trust source enforcement, tool failure handling
+- **Guard enforcement** - scope visibility (also through parent scopes, subscriptions and guard decisions), trust source enforcement, tool failure handling
+- **Conflicts across scope trees** - outer scope first, per-intent competing sets, deferred boundaries, leases and fencing tokens, equal-time intents in write order
 - **Composition** - agent manifest properties, scheduling
 - **Robustness** - garbage collection, thread safety under concurrent access
 - **Property-based ([Hypothesis](https://hypothesis.readthedocs.io/))** - randomized inputs, stateful scheduler fuzzing (register/unregister/update/tick sequences)
 - **Observability and cost controls** - telemetry sink non-interference, budget tracking accuracy, rate limit enforcement, fleet caps
+- **LLM client and stress-test pacing** - Retry-After handling, cached and reasoning token accounting, arrival-ordered pacing under rate limits (real threads)
+- **Stress-test safety metrics** - double bookings counted from the guard's decisions, recovered bookings apart, scope violations checked on every mark the harness hands an agent
 
 **[Stress test:](experiments/stress_test/analysis.md)** AI personal assistants for a simulated office - one per employee, plus adversarial agents that attempt to breach scope boundaries. No central scheduler, all coordination through the shared mark space. The scenario exercises 7 resource types across natural permission boundaries:
 
@@ -117,17 +120,17 @@ The reference implementation and experiments verify that the protocol's properti
 
 Department heads book with elevated priority. External system agents (parking bot, building ops) publish low-trust observations and warnings that decay over configurable half-lives. Adversarial agents with normal permissions but adversarial prompts attempt cross-department bookings and warning injection. All five mark types, all three conflict policies, and all three visibility levels produce non-trivial output in a single trial.
 
-Scenario design in [`design.md`](experiments/stress_test/design.md). Detailed analysis of resource allocation, agent behavior, temporal dynamics, and token economics in the [stress test writeup](experiments/stress_test/analysis.md).
+Scenario design in [`design.md`](experiments/stress_test/design.md). Detailed analysis of resource allocation, agent behavior, temporal dynamics, and token economics in the [stress test writeup](experiments/stress_test/analysis.md). A re-run on DeepSeek V4.1 Flash 1017 with a 2048-token thinking budget (one run, 2026-11-01) allowed no resource twice in one round and denied every cross-department write, with a mean manifest completion of 64.5% across departments against 58.8% for gpt-oss-120b; the two runs also differ in pacing and harness version ([section 9](experiments/stress_test/analysis.md#9-re-run-on-deepseek-v41-flash-1017)).
 
 **[Trial experiments:](experiments/trials/analysis.md)** 21 runs of the same scenario across 2 models - [OpenAI gpt-oss-120b](https://fireworks.ai/models/fireworks/gpt-oss-120b) (via Fireworks) and [Mercury 2](https://www.inceptionlabs.ai/blog/introducing-mercury-2), a diffusion-based LLM (via Inception AI). Agent counts from 105 (5 adversarial) to 1,050 (50 adversarial), 4,010 agent instances total.
 
-- **Adversarial** - agents with normal permissions but adversarial prompts attempt three attack modes (confidence manipulation, resource flooding, prompt injection). Zero safety violations on both models
-- **Safety** - zero double bookings and zero scope violations across all 21 runs
+- **Adversarial** - agents with normal permissions but adversarial prompts attempt three attack modes (confidence manipulation, resource flooding, prompt injection). No double booking found and every cross-department write denied, on both models
+- **Safety** - no resource allowed twice in one round, no lunch window over capacity, and every cross-department write denied, in all 21 runs (checked from their stored steps; [read leaks were not measured](experiments/trials/analysis.md#6-cross-experiment-safety))
 - **Repeatability** - 64.7% +/- 0.8% completion on gpt-oss-120b, 66.2% +/- 1.6% on mercury-2 (5 seeds each)
-- **Scaling** - up to 1,050 agents with proportionally scaled resources: per-agent step count nearly flat (1.2x at 10x scale), safety invariants hold at every scale point
+- **Scaling** - up to 1,050 agents with proportionally scaled resources: per-agent step count nearly flat (1.2x at 10x scale), no double booking found at any scale point
 - **Resource contention** - 5x more agents competing for the same resources: completion drops to 13.3% from resource scarcity, not protocol failure
 
-**[Defense stack trials:](experiments/trials/results/defense/analysis.md)** 6 attack modes (rate spike, type shift, privilege escalation, probe evasion, slow drift, combined) against the static enforcement layer + statistical envelope + diagnostic probe. 150 rounds, 105 agents per trial (5 adversarial). Zero safety violations across all attack modes. Full analysis in the [defense writeup](experiments/trials/results/defense/analysis.md).
+**[Defense stack trials:](experiments/trials/results/defense/analysis.md)** 6 attack modes (rate spike, type shift, privilege escalation, probe evasion, slow drift, combined) against the static enforcement layer + statistical envelope + diagnostic probe. 150 rounds, 105 agents per trial (5 adversarial). No double booking found across all attack modes (from the stored steps). Full analysis in the [defense writeup](experiments/trials/results/defense/analysis.md).
 
 **[Comparison experiment:](experiments/comparison/analysis.md)** Markspace vs a message-passing framework ([Microsoft Agent Framework](https://github.com/microsoft/agent-framework)) on a shared resource booking scenario. 10 agents, 12 slots, 10 seeds per arm.
 
@@ -146,7 +149,7 @@ The `markspace` package is a Python 3.11+ reference implementation. The protocol
 
 ```bash
 poetry install    # core package
-pytest            # 325 tests, no API key needed
+pytest            # 563 tests, no API key needed
 ```
 
 ### Use the protocol
@@ -233,7 +236,7 @@ See [`experiments/guide.md`](experiments/guide.md) for CLI reference and cost es
 ## Documentation
 
 - [`docs/framework.md`](docs/framework.md) - protocol design, biological foundations, composition, architecture, failure analysis
-- [`docs/spec.md`](docs/spec.md) - formal specification (70 properties, conformance checklist)
+- [`docs/spec.md`](docs/spec.md) - formal specification (76 properties, conformance checklist)
 - [`experiments/guide.md`](experiments/guide.md) - running experiments (setup, CLI reference, analysis, costs)
 - [`experiments/validation/`](experiments/validation/analysis.md) - safety, visibility, concurrency, scaling
 - [`experiments/stress_test/`](experiments/stress_test/) - 105-agent stress test ([design](experiments/stress_test/design.md), [analysis](experiments/stress_test/analysis.md))
@@ -259,7 +262,7 @@ Most users interact with `core.py` (types), `guard.py` (enforcement), and `space
 | [`telemetry.py`](markspace/telemetry.py) | Optional. OpenTelemetry-compatible metrics, structured logs, and trace context. |
 | [`compose.py`](markspace/compose.py) | Composition validation. Pipeline and manifest-permission checks. Stateless. |
 | [`schedule.py`](markspace/schedule.py) | Manifest-based scheduling with optional pre-activation budget checks. |
-| [`llm.py`](markspace/llm.py) | Provider-agnostic LLM client (OpenAI-compatible). |
+| [`llm.py`](markspace/llm.py) | Provider-agnostic LLM client (OpenAI-compatible), with `reasoning_effort`, cached and reasoning token accounting, and an optional per-request pacing hook (`RequestPacer`). |
 | [`models.py`](markspace/models.py) | Model registry. |
 
 ## Limitations

{markspace-0.2.0b0 → markspace-0.3.0b0}/docs/framework.md

@@ -154,6 +154,8 @@ Loosely similar to CAS (Compare-And-Swap) in concurrent programming (read state,
 
 **What it doesn't do**: Intent marks don't prevent all conflicts. Two agents could write intents simultaneously with high confidence. This creates a race condition resolved by the action mark: whoever writes the action first wins, the other agent reads the action mark and adapts.
 
+**Across a scope tree**: an intent competes with intents on the same resource in its own scope, its ancestors and its descendants, not in sibling scopes. The intent in the outer scope wins; inside one scope, the scope's policy decides; YIELD_ALL in either scope hands the pair to the principal. Each intent is judged against its own competing set, so no decision allows two competing intents, and the outcome does not depend on which scope's decision computes it ([spec 6.1](spec.md#61-resolution-protocol)). Among waiting claims, an outer-scope intent pre-empts inner-scope intents whatever their order or confidence. A granted claim holds a lease with a fencing token and is not pre-empted, and a successful action written through the guard is recorded only under its lease or as an uncontested direct claim ([Gray & Cheriton, 1989](https://doi.org/10.1145/74850.74870); [Burrows, 2006](https://www.usenix.org/legacy/event/osdi06/tech/burrows.html); [spec 6.5](spec.md#65-grants)). The costs: a crashed holder blocks the resource until its lease expires, and a tool that runs longer than its lease loses it, and its action is not recorded. Equal intents resolve in write order: each intent or action on a resource gets a later `created_at` than every earlier one on that resource in its scope, also when the clock has not moved (spec P32).
+
 **The consistency hybrid.** The protocol uses soft consistency for information sharing (observation marks decay, warnings fade, reinforcement is approximate) and hard consistency for mutual exclusion (the guard acquires a lock during conflict resolution to serialize resource claims). This is deliberate: information can tolerate eventual convergence, but "two agents must not book the same room" requires serialization. The stress test confirms this - HIGHEST_CONFIDENCE degenerates to FIRST_WRITER under the lock because the second agent finds an already-committed action, not a competing intent. The lock makes mutual exclusion reliable at the cost of reducing priority-based policies to first-come-first-served. Deferred resolution ([Spec Section 6.2](spec.md#62-deferred-resolution)) restores priority semantics by separating claim collection from allocation.
 
 ### Mark Type 2: Action
@@ -506,7 +508,7 @@ CREATE INDEX idx_mark_resource ON mark(resource_id, mark_type) WHERE resource_id
 
 #### Option A': Document database
 
-A document store (MongoDB, DynamoDB) is a natural alternative to PostgreSQL. Marks are document-shaped: varied schemas per type, nested content, queried by scope and time. Scope as partition key, `created_at` as sort key, TTL as native expiry. Trade-off: no schema migration when mark types evolve, but weaker transactional guarantees for atomic conflict checks (scope-partitioned guards sidestep this). Replaces Option A in the hybrid (Option C) if chosen.
+A document store (MongoDB, DynamoDB) is a natural alternative to PostgreSQL. Marks are document-shaped: varied schemas per type, nested content, queried by scope and time. Scope as partition key, `created_at` as sort key, TTL as native expiry. Trade-off: no schema migration when mark types evolve, but weaker transactional guarantees for atomic conflict checks (guards partitioned by scope tree sidestep this). Replaces Option A in the hybrid (Option C) if chosen.
 
 #### Option B: Redis streams
 
@@ -557,7 +559,7 @@ A complementary approach is consolidation: rather than keeping or discarding ind
 
 For multi-fleet deployments, synchronized pruning across mark spaces adds further complexity. [Bach (2025)](https://arxiv.org/abs/2506.17338) proposes a consensus-based Co-Forgetting Protocol for coordinated memory pruning in multi-agent systems, though this is heavier machinery than a single-fleet deployment needs.
 
-**Distributed storage.** The spec assumes a single-node mark space with in-process locking. A distributed deployment (multiple mark space nodes) would need to maintain the guard's atomicity guarantees across nodes. The guard's lock-based conflict check requires reading current state and making a decision atomically. A distributed guard would likely need either a [Calvin](https://doi.org/10.1145/2213836.2213838)-style deterministic ordering layer (Thomson et al., 2012) - where all nodes agree on transaction order before execution, so each can execute independently and arrive at the same result without distributed locking - or partitioning by scope (each scope assigned to exactly one node, reducing the problem back to single-node locking).
+**Distributed storage.** The spec assumes a single-node mark space with in-process locking. A distributed deployment (multiple mark space nodes) would need to maintain the guard's atomicity guarantees across nodes. The guard's lock-based conflict check requires reading current state and making a decision atomically. A distributed guard would likely need either a [Calvin](https://doi.org/10.1145/2213836.2213838)-style deterministic ordering layer (Thomson et al., 2012) - where all nodes agree on transaction order before execution, so each can execute independently and arrive at the same result without distributed locking - or partitioning by scope tree (all scopes under one root assigned to exactly one node, reducing the problem back to single-node locking). A partition must hold a whole tree: conflicts span a scope's ancestors and descendants, and the write order of claims is kept per resource within each scope (spec 6.1, P32).
 
 **Deferred resolution.** Formalized in [spec.md Section 6.2](spec.md#62-deferred-resolution). The deferred resolution pattern (collect intents, resolve at batch boundary) is used in the stress test for parking and boardroom resources. It is the mechanism that makes HIGHEST_CONFIDENCE meaningful under lock-based serialization ([Section 6.3 of the stress test analysis](../experiments/stress_test/analysis.md#63-lock-based-guards-break-highest_confidence)). The spec defines three phases (claim collection, resolution boundary, batch resolution), three properties (P14-P16), and the relationship between deferred and immediate guard modes. Remaining open question: the resolution boundary trigger is "deployment-defined," so a production implementation would need to decide between timer-based (resolve every N minutes), event-based (resolve when all expected intents are in or activity pauses), or principal-triggered (a human says "resolve now") boundaries - each trading off latency, completeness, and autonomy differently.
 
@@ -602,6 +604,8 @@ scope: "research/company/{company_id}"
 
 Scopes are hierarchical. An agent authorized for `research/company/*` can write marks on any company. An agent authorized for `research/company/ACME` can only write marks about ACME. Authority is scope-bounded, and scope is defined independently of the agents.
 
+A child scope may define its own visibility, decay and conflict policy. Each mark keeps its own scope's settings, also when read through a parent scope ([spec 7.4](spec.md#74-scope-visibility), [spec 8.2](spec.md#82-read)). Intents on one resource compete across the parent-child line, and the outer scope's intent wins ([Mark Type 1](#mark-type-1-intent)).
+
 ### Why This Decomposes
 
 The core claim is that each component can be designed, tested, and validated independently.
@@ -865,11 +869,11 @@ The protocol makes specific claims about what it prevents, mitigates, and delibe
 
 | Failure pattern | markspace mitigation | Status |
 |---|---|---|
-| Unauthorized access / scope violations | Scope permissions, guard rejects unauthorized writes | Prevented (0 violations) |
+| Unauthorized access / scope violations | Scope permissions, guard rejects unauthorized writes | Writes prevented: every cross-department write in the stored runs denied; reads not measured |
 | Cascading state corruption | Intent TTL (2h) prevents stale signal accumulation; decay degrades observations | Prevented (intents expired between every round pair) |
 | Unconstrained goal pursuit | Fixed manifests per agent, constrained tool space | Prevented (agents completed manifests, didn't improvise) |
 | Cross-agent propagation | No direct agent-to-agent communication; marks only | Prevented (all coordination through mark space) |
-| Resource exhaustion | Guard serialization + conflict resolution policies | Prevented (0 double bookings, 3 policies all functional) |
+| Resource exhaustion | Guard serialization + conflict resolution policies | Prevented: no double booking found in the stored runs (from their steps), 3 policies all functional |
 | Disproportionate response (CS1) | A protocol-valid action can still be harmful; no action proportionality checks | Not addressed |
 | Compliance with non-owner instructions (CS2) | Manifest can control whether an agent is authorized to interact with humans at all, but once authorized, what the agent shares is agent-internal | Not addressed |
 | Sensitive data disclosure (CS3) | Mark visibility controls structure, not content within agent outputs | Not addressed |
@@ -920,7 +924,7 @@ A natural question is what a complete multi-agent delegation system requires and
 | Trust and reputation | Partial | Three static source levels (fleet, verified, unverified). No dynamic trust updating, reputation, or experience-based trust. Sufficient for LLM non-compliance; insufficient for rational adversaries. |
 | Permission handling | Partial | Scope-based write authorization, hierarchical scope inheritance, three visibility levels (OPEN/PROTECTED/CLASSIFIED). No just-in-time authorization or privilege attenuation in sub-delegation chains. |
 | Verifiable task completion | Partial | Action marks record outcomes. Supersession chains track state transitions. No verification that the action's result is correct (the protocol records what happened, not whether it was right). |
-| Security | Yes | Guard enforces authorization independent of LLM compliance. Scope visibility prevents information leakage. Trust weighting attenuates untrusted sources. Adversarial robustness validated (171 denied attempts). |
+| Security | Yes | Guard enforces authorization independent of LLM compliance. Scope visibility controls who can read a mark, through reads, subscriptions and guard decisions. It does not control what an authorized reader writes afterwards: markspace has no write-down rule (see [CS3](#failure-mode-coverage)). A monitor can enforce such a rule, at the cost of blocking harmless writes, but not information flow itself ([Schneider, 2000](https://doi.org/10.1145/353323.353382)). Trust weighting attenuates untrusted sources. Adversarial robustness validated (171 denied attempts). |
 
 The gaps are intentional. Markspace covers what can be enforced structurally through environment design - shared state, authorization, conflict resolution. The components it omits (task decomposition, assignment, multi-objective optimization) require orchestration-level capabilities or agent-internal mechanisms that operate at a different architectural level.
 
@@ -932,7 +936,7 @@ Long-running agents accumulate history - tool outputs, observations, reasoning t
 
 Stigmergy reframes the problem. The mark space is both the coordination medium and the agents' shared context - agents don't carry private history that diverges, they read a common environment. Decay and TTL are the protocol's native context management: stale observations lose strength, expired intents vanish, warnings fade. This is structurally equivalent to observation masking - old signals attenuate without requiring an explicit compression step. The data itself (action marks, gathered observations, completed work) is valuable output that any system would store regardless of architecture.
 
-This design is structurally input-heavy: agents read the mark space every round but write only a few marks, producing [input-to-output ratios of 15:1 to 62:1](../experiments/trials/results/multi_trial/analysis.md#6-token-economics) depending on model verbosity (stress tests, 100+5 agents, 20 rounds). Input token price is the dominant cost factor, and model output verbosity barely matters. A model producing 5x fewer output tokens costs about the same per trial because output is already a small fraction of total spend.
+This design is structurally input-heavy: agents read the mark space every round but write only a few marks, producing [input-to-output ratios of 15:1 to 62:1](../experiments/trials/results/multi_trial/analysis.md#6-token-economics) depending on model verbosity (stress tests, 100+5 agents, 20 rounds). Input token price is the dominant cost factor, and model output verbosity barely matters. A model producing 5x fewer output tokens costs about the same per trial because output is already a small fraction of total spend. A thinking budget moves cost toward output: DeepSeek V4.1 Flash 1017 with a 2048-token budget ran at 11:1 in the 10-round stress test (gpt-oss-120b: 17.8:1 there), and output was 31% of the run's cost, against 18% for gpt-oss-120b ([stress test, section 9](../experiments/stress_test/analysis.md#9-re-run-on-deepseek-v41-flash-1017)).
 
 Mark space size directly drives token cost - every mark in the active read set is tokens an agent consumes each round. Marks below a strength threshold add tokens without adding signal; a fully-decayed observation at 0.01 strength costs the same tokens as a fresh one at full strength. A production system needs a read-path cutoff: marks below a configurable strength threshold are excluded from agent reads but retained in storage. The [hybrid architecture](#option-c-hybrid-recommended) already separates hot state (Redis) from durable record (PostgreSQL) - the read-path cutoff determines what stays in the hot layer. See [Open Questions](#open-questions) for the unbounded growth problem.
 
@@ -942,22 +946,25 @@ The guard mediates every write and enforces every conflict resolution. Two thing
 
 ### Telemetry
 
-The guard emits structured events on every `write_mark()` and `execute()` call. Events go to a telemetry sink, not into the mark space. The interface is [OpenTelemetry](https://opentelemetry.io/)-compatible: metrics as instruments, structured logs as log records, and optional trace context propagation. Implementations SHOULD use the OpenTelemetry SDK when available and MAY fall back to structured JSON logs.
+The guard emits structured events on every `write_mark()` and `execute()` call. Events go to a telemetry sink, not into the mark space. Lease grants, expiries and losses are counted on the call that records them. The interface is [OpenTelemetry](https://opentelemetry.io/)-compatible: metrics as instruments, structured logs as log records, and optional trace context propagation. Implementations SHOULD use the OpenTelemetry SDK when available and MAY fall back to structured JSON logs.
 
 **Metrics** (counters, gauges, histograms):
 
-| Metric | Type | Labels | What it tells you |
-|--------|------|--------|-------------------|
-| `markspace.marks.written` | Counter | `agent_id`, `scope`, `mark_type`, `verdict` | Write volume and rejection rate per agent |
-| `markspace.marks.read` | Counter | `agent_id`, `scope` | Read volume per agent per round |
-| `markspace.tokens.input` | Counter | `agent_id` | Input tokens consumed per round |
-| `markspace.tokens.output` | Counter | `agent_id` | Output tokens generated (LLM responses + mark writes) |
-| `markspace.conflicts.resolved` | Counter | `scope`, `policy`, `outcome` | Conflict frequency and resolution distribution |
-| `markspace.space.active_marks` | Gauge | `scope`, `mark_type` | Hot-tier mark count (above strength threshold) |
-| `markspace.space.total_marks` | Gauge | `scope`, `mark_type` | Total mark count including decayed |
-| `markspace.agent.budget.remaining` | Gauge | `agent_id`, `dimension` | Remaining token budget (input/output/total) |
-| `markspace.agent.round.duration` | Histogram | `agent_id` | Wall-clock time per agent round |
-| `markspace.needs.pending` | Gauge | `scope` | Unresolved need marks awaiting principal review |
+| Metric | Type | Labels | Emitted by | What it tells you |
+|--------|------|--------|------------|-------------------|
+| `markspace.marks.written` | Counter | `agent_id`, `scope`, `mark_type`, `verdict` | guard | Write volume and rejection rate per agent |
+| `markspace.marks.read` | Counter | `agent_id`, `scope` | deployment | Read volume per agent per round |
+| `markspace.tokens.input` | Counter | `agent_id` | guard | Input tokens consumed per round |
+| `markspace.tokens.output` | Counter | `agent_id` | guard | Output tokens generated (LLM responses + mark writes) |
+| `markspace.conflicts.resolved` | Counter | `scope`, `policy`, `outcome` | guard | Conflict frequency and resolution distribution |
+| `markspace.leases.granted` | Counter | `scope`, `resource` | guard | Grants per resource (spec 6.5) |
+| `markspace.leases.expired` | Counter | `scope`, `resource` | guard | Leases that reached their expiry: tools slower than their lease |
+| `markspace.leases.lost` | Counter | `scope`, `resource` | guard | Intents closed as lost: refused or beaten |
+| `markspace.space.active_marks` | Gauge | `scope`, `mark_type` | deployment | Hot-tier mark count (above strength threshold) |
+| `markspace.space.total_marks` | Gauge | `scope`, `mark_type` | deployment | Total mark count including decayed |
+| `markspace.agent.budget.remaining` | Gauge | `agent_id`, `dimension` | deployment | Remaining token budget (input/output/total) |
+| `markspace.agent.round.duration` | Histogram | `agent_id` | deployment | Wall-clock time per agent round |
+| `markspace.needs.pending` | Gauge | `scope` | deployment | Unresolved need marks awaiting principal review |
 
 **Structured logs** (one per guard decision):
 
@@ -975,7 +982,7 @@ The guard emits structured events on every `write_mark()` and `execute()` call.
 }
 ```
 
-**Trace context.** Each agent round MAY carry an OpenTelemetry span context. The guard propagates this context to downstream tool calls, so a single trace connects: agent activation - mark space read - LLM call - tool execution - mark write - guard decision.
+**Trace context.** Each agent round MAY carry an OpenTelemetry span context. The guard MAY propagate this context to downstream tool calls, so a single trace connects: agent activation - mark space read - LLM call - tool execution - mark write - guard decision. The reference guard does not propagate it.
 
 Telemetry observes the mark space boundary, not agent internals. Reasoning traces, prompt compliance, and hallucination rates require agent-level instrumentation (e.g., LLM provider callbacks) that sits alongside the protocol.
 
@@ -1002,7 +1009,7 @@ message AgentManifest {
 
 When omitted, the budget is unbounded.
 
-Input and output budgets are separate because they have different cost profiles. Input tokens are the dominant cost factor ([15:1 to 62:1 input-to-output ratio](../experiments/trials/results/multi_trial/analysis.md#6-token-economics)) and are driven by mark space size - something the agent doesn't control. Output tokens reflect agent verbosity and model choice - something the operator controls through model selection and prompting.
+Input and output budgets are separate because they have different cost profiles. Input tokens are the dominant cost factor ([15:1 to 62:1 input-to-output ratio](../experiments/trials/results/multi_trial/analysis.md#6-token-economics); [11:1](../experiments/stress_test/analysis.md#9-re-run-on-deepseek-v41-flash-1017) for a model with a 2048-token thinking budget, 10 rounds) and are driven by mark space size - something the agent doesn't control. Output tokens reflect agent verbosity and model choice - something the operator controls through model selection and prompting.
 
 **Enforcement.** The scheduler checks remaining budget before activating an agent. The guard tracks cumulative token usage across rounds.
 
@@ -1046,6 +1053,8 @@ Stigmergy isn't new to computer science, though it has seen limited adoption for
 
 **Hoare monitors** ([Hoare, 1974](https://doi.org/10.1145/355620.361161)): the guard layer ([Section 9 of the spec](spec.md#9-guard-deterministic-enforcement-layer)) is a descendant of Hoare's monitor concept. A monitor wraps shared state with procedures that enforce mutual exclusion and preconditions. The guard wraps the mark space: every tool call passes through `pre_action` (precondition check) before execution, with a lock ensuring atomicity. The difference is that Hoare monitors enforce programmer-specified invariants, while the guard enforces protocol-specified invariants that the LLM agent cannot override.
 
+**Execution monitoring** ([Schneider, 2000](https://doi.org/10.1145/353323.353382); [Hamlen, Morrisett & Schneider, 2006](https://doi.org/10.1145/1111596.1111601)): the theory of what the guard can enforce. A monitor watches each step and stops it before it breaks a policy, so it enforces safety properties whose check on the finite history is decidable (after [Viswanathan, 2000](https://repository.upenn.edu/dissertations/AAI9989666/)). The guard is such a monitor: scope authorization, schema validation, conflict checks and rate limits decide on the mark history and the proposed call before it runs. A content policy or the statistical envelope enforces only the rule its code states, not "observations are true" or "this message causes no harm", which depend on what the guard cannot observe. Scope authorization and schema validation run inside `write()`; the other checks hold only when every call goes through the guard ([spec 9.1](spec.md#91-principle)).
+
 **Bell-LaPadula model** ([Bell & LaPadula, 1973](https://apps.dtic.mil/sti/citations/AD0770768)): the OPEN/PROTECTED/CLASSIFIED visibility levels are a simplified Bell-LaPadula lattice. Bell-LaPadula's "no read up, no write down" becomes our "unauthorized readers see projections (PROTECTED) or nothing (CLASSIFIED)." The simplification is deliberate: the Bell-LaPadula model handles hierarchical security levels combined with compartment categories (related to [Denning's (1976)](https://doi.org/10.1145/360051.360056) lattice model of secure information flow); we need exactly three levels because the use case is coordination visibility, not military classification. The projected read (structure visible, content redacted) is the novel element. Bell-LaPadula has no analogue for "you can see that a mark exists but not what it says."
 
 **Environment as first-class abstraction** ([Weyns et al., 2007](https://doi.org/10.1007/s10458-006-0012-0)): Weyns, Omicini, and Odell argued that multi-agent system environments should be first-class architectural elements with their own responsibilities, not just passive containers. The mark space follows this prescription: it computes strength at read time, enforces visibility, and mediates all agent interaction. Agents do not interact with each other; they interact with the environment.
@@ -1106,7 +1115,7 @@ Recent work has applied coordination protocols to LLM agent fleets, though most
 
 **Agent Identity URI Scheme** ([Rodriguez, 2026](https://arxiv.org/abs/2601.14567)): proposes `agent://` as a stable, topology-independent naming scheme for multi-agent systems, combining an organizational trust root, a hierarchical capability path for semantic discovery, and a sortable unique identifier. The capability path (e.g., `/workflow/approval`) enables agents to locate collaborators by what they can do rather than by pre-configured identity - complementing markspace's static fleet composition with a dynamic discovery layer. Cryptographic attestation via PASETO tokens tied to the trust root provides a structural basis for cross-fleet identity verification. Most directly relevant to the cross-principal surface: attestation could upgrade incoming external marks to `EXTERNAL_VERIFIED` without manual cross-referencing, and capability paths enable runtime discovery of external fleet agents. The scheme assumes the attestation layer is the threat boundary and does not address adversarial agents operating within a legitimate trust root.
 
-**Gap this work addresses.** Shared-state coordination is well-established (blackboard systems, tuple spaces, shared databases). Stigmergic decay and reinforcement have been studied in swarm intelligence since the 1990s. The specific gap is the combination, adapted for LLM agents: (1) a typed mark taxonomy with formal decay/trust semantics designed for probabilistic, exploitable agents, (2) a deterministic enforcement layer independent of LLM compliance, (3) systematic experimental validation across adversarial, concurrent, and multi-resource conditions, and (4) a formal specification with property tests covering normative guarantees. Several of these components draw directly from prior work - decay from pheromone evaporation (Dorigo et al., 1996), trust weighting from reputation models (Granatyr et al., 2015), the enforcement layer from Hoare monitors (1974), visibility from Bell-LaPadula (1973). The mark taxonomy (the specific 5-type decomposition oriented around coordination failure modes), projected reads (structure-visible, content-redacted access that Bell-LaPadula has no analogue for), and the empirical validation at scale under adversarial pressure are new contributions. The broader contribution is their integration into a protocol adapted for agents that are probabilistic, exploitable, and operating in environments where information goes stale - properties that prior shared-state systems did not design for. The attack surfaces documented in 2025-2026 security research - trust-authorization mismatch where static permissions decouple from runtime trustworthiness ([Shi et al., 2025](https://arxiv.org/abs/2512.06914)), prompt injection escalating through multi-stage kill chains ([Brodt et al., 2026](https://arxiv.org/abs/2601.09625)), and peer agents bypassing refusal guardrails that hold against direct prompting ([Lupinacci et al., 2025](https://arxiv.org/abs/2507.06850)) - are instances of these failure modes in deployed systems.
+**Gap this work addresses.** Shared-state coordination is well-established (blackboard systems, tuple spaces, shared databases). Stigmergic decay and reinforcement have been studied in swarm intelligence since the 1990s. The specific gap is the combination, adapted for LLM agents: (1) a typed mark taxonomy with formal decay/trust semantics designed for probabilistic, exploitable agents, (2) a deterministic enforcement layer independent of LLM compliance, (3) systematic experimental validation across adversarial, concurrent, and multi-resource conditions, and (4) a formal specification with property tests covering normative guarantees. Several of these components draw directly from prior work - decay from pheromone evaporation (Dorigo et al., 1996), trust weighting from reputation models (Granatyr et al., 2015), the enforcement layer from Hoare monitors (1974), visibility from Bell-LaPadula (1973). What the enforcement layer can guarantee follows from execution monitoring theory ([Schneider, 2000](https://doi.org/10.1145/353323.353382); [Hamlen et al., 2006](https://doi.org/10.1145/1111596.1111601)): safety properties with a decidable check, not properties that depend on what the guard cannot observe, such as whether content is true or causes harm. The mark taxonomy (the specific 5-type decomposition oriented around coordination failure modes), projected reads (structure-visible, content-redacted access that Bell-LaPadula has no analogue for), and the empirical validation at scale under adversarial pressure are new contributions. The broader contribution is their integration into a protocol adapted for agents that are probabilistic, exploitable, and operating in environments where information goes stale - properties that prior shared-state systems did not design for. The attack surfaces documented in 2025-2026 security research - trust-authorization mismatch where static permissions decouple from runtime trustworthiness ([Shi et al., 2025](https://arxiv.org/abs/2512.06914)), prompt injection escalating through multi-stage kill chains ([Brodt et al., 2026](https://arxiv.org/abs/2601.09625)), and peer agents bypassing refusal guardrails that hold against direct prompting ([Lupinacci et al., 2025](https://arxiv.org/abs/2507.06850)) - are instances of these failure modes in deployed systems.
 
 
 ## References
@@ -1197,6 +1206,11 @@ Recent work has applied coordination protocols to LLM agent fleets, though most
 - Hoare, C.A.R. (1974). "Monitors: An Operating System Structuring Concept." *Communications of the ACM*, 17(10), 549-557. [doi:10.1145/355620.361161](https://doi.org/10.1145/355620.361161). [Monitors: mutual exclusion + preconditions on shared state. Ancestor of the guard layer.]
 - Bell, D.E. & LaPadula, L.J. (1973). "Secure Computer Systems: Mathematical Foundations." MITRE Technical Report MTR-2547. [DTIC:AD0770768](https://apps.dtic.mil/sti/citations/AD0770768). [Bell-LaPadula model: mandatory access control lattice. Ancestor of OPEN/PROTECTED/CLASSIFIED visibility.]
 - Denning, D.E. (1976). "A Lattice Model of Secure Information Flow." *Communications of the ACM*, 19(5), 236-243. [doi:10.1145/360051.360056](https://doi.org/10.1145/360051.360056). [Lattice model of information flow security.]
+- Schneider, F.B. (2000). "Enforceable Security Policies." *ACM Transactions on Information and System Security*, 3(1), 30-50. [doi:10.1145/353323.353382](https://doi.org/10.1145/353323.353382). [Execution monitors enforce only safety properties. Access control is one; information flow is not. Monitors in tandem enforce the conjunction of their policies.]
+- Hamlen, K.W., Morrisett, G., & Schneider, F.B. (2006). "Computability Classes for Enforcement Mechanisms." *ACM Transactions on Programming Languages and Systems*, 28(1), 175-205. [doi:10.1145/1111596.1111601](https://doi.org/10.1145/1111596.1111601). [Static analysis enforces exactly the decidable policies; execution monitors enforce a subset of the co-recursively enumerable (coRE) properties, including policies whose static check is the Halting Problem. A monitor cannot enforce a policy whose critical events it cannot observe.]
+- Viswanathan, M. (2000). "Foundations for the Run-time Analysis of Software Systems." PhD thesis, University of Pennsylvania. [repository.upenn.edu](https://repository.upenn.edu/dissertations/AAI9989666/). [Adds the condition that an execution monitor's check on each finite prefix be computable; cited after Hamlen et al. (2006).]
+- Gray, C., & Cheriton, D. (1989). "Leases: An Efficient Fault-Tolerant Mechanism for Distributed File Cache Consistency." *Proceedings of the Twelfth ACM Symposium on Operating Systems Principles (SOSP '89)*, 202-210. [doi:10.1145/74850.74870](https://doi.org/10.1145/74850.74870).
+- Burrows, M. (2006). "The Chubby lock service for loosely-coupled distributed systems." *7th USENIX Symposium on Operating Systems Design and Implementation (OSDI '06)*. [usenix.org](https://www.usenix.org/conference/osdi-06/presentation/chubby-lock-service-loosely-coupled-distributed-systems).
 - Dorigo, M., Maniezzo, V., & Colorni, A. (1996). "Ant System: Optimization by a colony of cooperating agents." *IEEE Transactions on Systems, Man, and Cybernetics*, 26(1), 29-41. [doi:10.1109/3477.484436](https://doi.org/10.1109/3477.484436). [Ant Colony Optimization.]
 - Brambilla, M., Ferrante, E., Birattari, M., & Dorigo, M. (2013). "Swarm robotics: a review from the swarm engineering perspective." *Swarm Intelligence*, 7(1), 1-41. [doi:10.1007/s11721-012-0075-2](https://doi.org/10.1007/s11721-012-0075-2). [Survey of stigmergic coordination in swarm robotics.]
 - Parunak, H.V.D. (2006). "A survey of environments and mechanisms for human-human stigmergy." *Environments for Multi-Agent Systems II*, LNAI 3830, 163-186. [doi:10.1007/11678809_10](https://doi.org/10.1007/11678809_10). [Stigmergic coordination in human systems.]