Skip to content

ADR-067: Target Project Evidence Isolation & Positive Boundary Containment

Status

Accepted

Date

2026-08-31

Context

During the onboarding diagnostic of an external project (EA4ALL), CAS generated architectural baselines and evolution maps that predominantly described the CAS platform implementation engine (ideas-to-life-cas) rather than the target project being analyzed (ea4all). The diagnostic identified that:

  1. Foundational asset loading (load_foundational_assets) loaded engine source files (src/**/*.md) relative to process CWD and global CAS platform ADRs into the target project evidence set.
  2. Baseline discovery extracted historical dates (such as 2024-05-22 from CAS engine ADRs) into target project baseline artifacts.
  3. CLI commands and portal preprocessors defaulted to ideas-to-life-cas identity.

Initial remediation proposals considered creating an accumulating list of path-specific negative exclusions (such as excluding src/**/*.md, portal/**, and knowledge/**). However, negative path filtering is fragile, non-scalable, and breaks when new engine directories are introduced.

Architectural Invariant

"Target Project Repository Root defines Project Evidence."

Decision

Adopt structural Positive Boundary Containment for target project evidence isolation across the Continuous Architecture System (CAS):

  1. TargetProjectContext Prerequisites: Prior to evidence discovery, every CAS workflow execution MUST establish an authoritative TargetProjectContext containing, at minimum:
  2. project_id (canonical slug)
  3. project_root (absolute path to project root)

  4. evidence_root (absolute path to target project evidence root)

  5. Positive Boundary Containment: Foundational project evidence discovery MUST operate strictly within the evidence_root established by TargetProjectContext (which resolves to the target project's repository root or an explicitly defined evidence path beneath it). The target project’s repository root defines the maximum project-evidence boundary; evidence_root defines the authoritative evidence scope within that boundary.

  6. No Accumulating Negative Exclusion Lists: Files outside evidence_root (including CAS engine code, platform docs, workflow implementations, templates, and portal assets) are excluded structurally by boundary containment. CAS MUST NOT rely on path-specific negative exclusion rules (such as src/**/*.md or portal/**).

  7. Symmetric Execution Rules: The exact same foundational loader implementation and boundary rules apply whether analyzing the CAS platform itself (project_id: ideas-to-life-cas) or an external target project (project_id: ea4all).

  8. Explicit Reference Mechanisms for Shared Context: Shared or cross-project CAS knowledge MUST be accessed through explicit, declared reference mechanisms rather than being automatically ingested into a project's foundational evidence bundle.

  9. Dynamic Portal Discovery & Resolution: TargetProjectContext and cas-config.yaml serve as the single source of project identity across CLI, runner, reference resolution, and Portal preprocessing.

Alternatives Considered

Alternative 1: Accumulating Negative Path Exclusion Filters (src/**/*.md, portal/**, knowledge/**)

  • Pros: Quick to patch in load_foundational_assets().
  • Cons: Fragile, maintenance-heavy, incomplete (fails to catch new engine paths), and breaks symmetry when CAS itself is the target project.
  • Outcome: Rejected.

Alternative 2: Textual Prompt Guardrails ("Do not analyze CAS; analyze EA4ALL")

  • Pros: Zero code changes to loaders.
  • Cons: Violates NFR-05; non-deterministic, consumes prompt window, fails to prevent upstream context contamination.
  • Outcome: Rejected.

Consequences

  • Positive:
  • Robust, deterministic project isolation grounded in structural filesystem containment.
  • Complete elimination of engine code leaking into external project baselines.
  • Provenance of baseline dates is strictly traceable to target project evidence or current execution temporal context (date.today().isoformat()).
  • Identical loader logic works symmetrically for CAS platform self-analysis and external project analysis.
  • Negative:
  • Requires all CLI entrypoints and runners to construct TargetProjectContext before invoking evidence discovery.
  • Requires cas-config.yaml or explicit --repo-root flags when executing outside a standard project workspace layout.

Traceability

Artefact ID
Specification specs/067-ea4all-onboarding-remediation/spec.md
Requirement Spec docs/requirements-spec/cas-ea4all-onboarding-remediation-req-spec.md
Implementation Plan specs/067-ea4all-onboarding-remediation/plan.md