Assay-Runner Boundary And Extraction Map¶

Internal Phase 2A reference. This page defines the current Assay-Runner boundary candidate after the delegated Linux/eBPF Phase 1 proof. It is not a repository-split plan and does not create a released product surface.

Phase 1 proved that Assay can produce deterministic measured-run bundles on a delegated Linux/eBPF host. Phase 2A keeps that proof reviewable while the runner boundary is consolidated. Extraction is only possible after the boundary is stable; it is not the goal of this document.

Core Rule¶

Assay remains the owner of artifact semantics.

Runner may own measured execution, layer capture orchestration, cgroup-scoped process placement, and correlation mechanics. Runner must not become an independent authority for what an Assay evidence artifact means.

Implications:

• artifact schemas stay owned by Assay core/reference docs
• archive verification stays an Assay responsibility
• runner-generated bundles must remain verifiable through Assay evidence semantics
• runner projection or capability diff may consume artifacts, but must not redefine them

Boundary Table¶

Dependency Direction¶

Allowed dependency direction:

Assay core semantics
  -> runner measured execution
  -> harness/report projection

Forbidden direction:

runner implementation detail
  -> redefines Assay artifact meaning

Runner code may depend on Assay core crates or exported contracts. Assay core must not depend on a publishable runner crate for artifact interpretation. If a core crate needs a helper currently living in runner-spike code, move the helper to the appropriate core module first and cover that move with tests.

Additional extraction rule:

1. If a runner candidate module contains artifact schema or data-structure definitions needed by both Assay and a future runner repository, those definitions must migrate to an Assay-owned shared contract before extraction. The runner may fill those structures, but it may not be the sole owner of their meaning across a repository boundary.

Current In-Repo Ownership¶

The current spike surfaces remain in Rul1an/assay:

Active Boundary Conflicts¶

These are the known hard cases. Do not resolve them by moving code first and explaining the ownership later.

If a future PR touches one of these conflicts, reviewers should require a contract update or an explicit statement that the PR does not change the boundary.

What Must Never Move Alone¶

The following cannot be moved to a separate runner repository without an explicit shared-contract replacement:

• artifact schema definitions
• archive verification semantics
• observation-health status meanings
• telemetry-versus-evidence filter rationale
• CI lane decision table
• fixture v0 contract
• delegated proof acceptance note

If extraction happens later, these must either stay in Assay core or become a versioned shared contract package consumed by both repositories.

Extraction Readiness Criteria¶

Do not create a separate Assay-Runner repository until all of the following are true:

If the boundary map remains materially unstable after a 4-6 week consolidation window, treat that as evidence that extraction is premature. Do not force a repository split while the ownership line is still moving.

The consolidation window is an evidence requirement, not a calendar requirement. After Phase 2D Slices 1-6B landed, the passive 4-6 week wait is replaced by the burn-in criteria defined in phase-2d-consolidation-audit.md. The burn-in criteria are the new satisfaction condition for this consolidation gate; they are not necessarily satisfied yet — the audit page tracks which criteria are observed and which are still pending. Counting weeks without observing repo behavior is weak evidence; the audit page makes the evidence concrete.

Extraction Blocking Conditions¶

Extraction is blocked if any of these are true:

• assay.runner.*.v0 schemas still need breaking changes to remain useful
• delegated CI selection still depends on reviewer intuition rather than the CI lane contract
• fixture stability requires undocumented local knowledge
• tool_call_id fallback semantics are being decided implicitly
• runner schema definitions are still coupled to Assay internals in ways a future runner repository would need to import
• runner orchestration still depends on assay-cli-local cgroup helpers without a stable API boundary
• runner crate build boundaries require more Assay internals than a deliberate shared schema/monitor contract allows
• macOS or Windows support is being treated as a port rather than a separate platform spike
• a separate repo would need to copy Assay evidence verification logic
• runner code cannot be tested without private host state that is absent from the delegated runbook
• there is no non-spike consumer of the runner bundle format

Future Split Shape¶

If extraction becomes justified, the likely shape is:

The first extracted release, if it ever exists, should be narrow: Linux/eBPF delegated measured runs with the existing none, kernel+policy, and OpenAI Agents fixture paths. It should not bundle macOS, live LLM calls, fleet operations, or OTel mappings into the first boundary.

Non-Goals¶

This boundary map does not:

• choose an external product name
• create a new repository
• promise publication or packaging
• define macOS or Windows measurement
• define live LLM or cassette semantics
• define OTel mappings
• change delegated acceptance criteria

Those decisions require separate contracts after the Linux boundary is stable.