Chapter 8 — Evidence and Evaluation

8.1 Subject and Evidence Basis

This chapter evaluates what the available evidence establishes about Root's shared instructions, roles, methods, queries and connecting paths. Its source basis is commit a602024416ace9652f61bb2043889c307fd4e09d. The analysis concerns that implementation and its recorded examinations; it is not a fresh audit of the current products. Appendix E preserves the development record, earlier arrangements and the limits of that history.

Root's principal contribution is normative: purposes, responsibilities, distinctions and criteria guide work while remaining open to correction. Its tools also make some relationships operable. The App supplies the chiefly operative perspective; Piping supplies the chiefly evaluative perspective as a domain-software instance. Evidence in one perspective can inform another without establishing its claims. Ontology, epistemology, praxeology and axiology concern all three.

The evaluation distinguishes specification, exercised behaviour and adequacy for use. A written contract establishes what was required. A passing check establishes what its inputs and predicates exercised. Professional adequacy and human engagement need grounds appropriate to their own subjects.

8.2 Authorization and Enforced Boundaries

8.2.1 Responsibility and Authorization

The source basis contains four general role files:

These contributions describe responsibility. Human assignment and adopted policy establish authorization; the host supplies capability and enforces permissions on its actual paths. One session can carry several contributions. Agent 0's continuing responsibilities need not imply a separate managerial tier.

8.2.2 Exercised Permission Behaviour

PR #1223 couples the HELP_HUMAN authorization interpretation with resolver boundary tests. The resolver retains authorized write targets while denying unauthorized targets and respecting a read-only host. Tests cover absent authorization and escaping targets, including symlink escapes. This supports the resolver behaviour under the examined conditions.

That result does not establish containment of every command, host or App entry point. An instruction, a tested path predicate and an operating-system sandbox have different coverage. App v4's role configuration remains a product contract. The workflow resolver contract defines its own operations; a claim about broader containment requires evidence about broader paths.

8.3 Access to Relevant Meaning

8.3.1 Current Sources and Queries

Active project deliverables maintain commitments and acceptance criteria in ScopeOfWork.md, useful technical reasoning in Design/, and consumer-owned needs and conditions in deliverable.yaml. The Root entry locates the shared component and affected consumers; an active project entry locates product commitments. The authorized undertaking directs the inquiry.

The deliverable CLI exposes neighborhood, impact, touches, dag-diff and check. It reports source locations and its observed basis, including working-tree changes. Code mappings indicate relevance, not exclusive ownership. Missing mappings leave a partial answer rather than proving absence of consumers.

check rejects malformed data and invalid or escaping identities and paths. Unresolved suppliers, planned paths and cycles are reported distinctly. Mutual or non-gating relationships can legitimately form cycles. The checker does not establish an input's suitability; an agent must examine its condition and actual contents within the assignment.

8.3.2 Preservation of Meaning Through Transformation

App v4 PR #1213 and Piping PR #1216 provide bounded evidence about preservation of dependency conditions. Source-row accounting and comparison with identified graph bases detect omitted or changed declarations. Independent examination of meanings complements those mechanical checks.

This supports preservation on the examined basis. It establishes neither that the source declarations captured every real dependency nor that any supplier met its consumer's condition. Several distinct conditions between the same pair of deliverables must remain intelligible; reducing them to one readiness label would lose part of the relationship.

8.3.3 Method Selection and Actual Consumers

Methods are indexed in workflows/index.json and selected as needed. The resolver specifies ordered selection, explicit resources and source identities. Missing or escaping selected resources fail resolution; omitted resources are not read. Returned hashes identify the inputs read by the resolver. They do not establish that the host delivered them to an agent or that the agent applied the method.

The workflow index builder connects package metadata to the catalog. An adopted App bundle is a separate consumer. The useful evidence concerns the saved source, selected identity, affected consumer and checked connection. Updating a shared source alone cannot establish adoption by each product.

8.4 Production, Examination and Integration

8.4.1 Continuing Ownership

The coordinated-knowledge-work workflow organizes purpose, integration, contributions and scrutiny. Owners remain with ordinary repairs. Independent work can continue while an unrelated branch is unresolved; shared writes, interfaces, resources and review capacity can require coordination. A missing declared edge cannot prove independence.

The implementation supplies a usable method, not proof that every undertaking retains intent or reaches integration. Continuity draws on current artifacts, conversation, tool queries and Git history, with recovery support where needed. Recovery requires evidence from an actual continuation: a preserved conversation alone does not establish that work resumed without loss or duplicated action.

8.4.2 Selected Checks and Reuse

The CI selection reference defines harness as the required aggregate result for repository checks and selected active-product workflows. Unrelated jobs can be skipped explicitly. A selected failed, cancelled or missing job must prevent the aggregate from passing. Selection and failure propagation are distinct properties requiring examination.

PR #1214 supplies recorded checks of that selection. Applicable prior passes can be reused, with the explicit qualification that no new tests executed. A build cache is not a prior test result; manual runs can obtain fresh evidence. Reuse depends on applicability to the candidate and concern, rather than the mere existence of a green result.

The repository selects targeted regression checks and independent scrutiny for numerical meaning, persistence, permissions and destructive operations. Routine reversible work can be inspected or exercised directly. This selection principle makes consequence and detectability relevant; it cannot establish that every important behaviour was selected or that the checks cover it adequately.

8.4.3 Evidence at Connecting Paths

The integration reviews recorded in Appendix E identified live technical references among intended removals. Repair needed both relocation and consumer updates. A passing generated-product test did not establish that the next generator invocation would remain usable. The connecting path, rather than the isolated component, was the subject requiring examination.

App PR #1240 supplies a different witness: actual native interaction exposed role-header accumulation and input autocorrection defects, followed by repair. This supports exercising the assembled application. It does not establish general usability or absence of other defects. The appropriate finding concerned product behaviour and prompted product repair.

Agents can perform extensive reckoning on such evidence: inference, criticism, comparison, investigation and authorized action. Human judgment sets and revises the undertaking's purpose and what the person can stand behind throughout. Independent agent scrutiny can improve the grounds without performing that person's act of reliance.

8.5 App and Domain-Software Evidence

8.5.1 Operative Perspective: The App

The App PRD, architecture and App thesis define the application-specific inquiry. Conversations, request cards, workflow authoring, trial runs and inspection of returned work supply operative paths through which intent and methods can be tried and revised.

The host-integration contract proposes discoverable application capabilities. A common catalog does not establish correct domain behaviour, good interfaces, recovery or every transport adapter. PR #1244 assigns file and record writes, supplier interaction and capture of human acts to the Rust host, while the web view presents and sends human-initiated requests. This ruling is a product commitment; its text alone does not establish conformance of all paths.

An accepted act and substantive engagement remain different claims. Capturing a human action can support attribution and identify its subject. It cannot establish that the person understood the consequences or performed adequate professional examination.

8.5.2 Evaluative Perspective: Piping

The Piping PRD distinguishes physical models, analytical models, analysis runs, comparison and handoff. These objects need domain definitions, numerical implementation and evidence. The SWBPIPE thesis examines that instantiation, including the limits of its calculations and engineering use.

Operation validation, numerical verification and engineering adequacy answer different questions. Operation validation examines whether a proposed change satisfies the engine's defined conditions. Numerical verification examines calculation against an appropriate reference or method. Engineering adequacy concerns whether physical intent, model assumptions, cases, alternatives and results support the proposed use. Passing the first cannot establish the others.

The illustrative support-arrangement revision links those questions to practical alternatives and the person's choice and revision. It is an illustration, not measured evidence. Piping is one domain-software instance; its numerical results do not establish economical transfer to all domains.

8.5.3 Iterative Feedback

A domain finding can reveal a missing distinction in Root's criteria. An App refusal or recovery failure can reveal an inadequate operative path. A changed physical purpose can require another model or alternative. Iterative feedback means that these findings can revise each perspective and their relationships. The four philosophical questions recur across that feedback rather than assigning one pillar to one thesis or fixing a mandatory sequence.

A successive implementation also needs examination of retained learning. A new PRD or version number cannot establish that prior defects, useful interfaces and owner decisions were considered. Root's source accessibility helps that inquiry; actual receiving-product evidence must establish the result.

8.6 Assessment and Remaining Questions

The basis supports feasibility of specific mechanisms and production paths. Repository instructions, role files, selected methods, deliverable sources and the query CLI are in use; the relevant Git and CI paths have been exercised. PR #1238 provides the accepted manuals describing that working model. Their existence does not imply that the whole system is fully validated.

Evaluation must include applicable obligations, uncertain premises, negotiable preferences and control costs separately. Required conditions retain their standing. Attention, delay, maintenance, false alarms and missed-error consequences matter in choosing how to meet them. More records or checks need a concrete contribution to the work; fewer controls need evidence that their functions are unnecessary or adequately served elsewhere. There is no universal scalar or mandated process that resolves this assessment.

The most useful further investigations concern connecting paths: whether a fresh participant finds a governing condition and its supplier; whether a method change reaches its adopted consumer; whether a reviewer receives the candidate and actual basis; and whether interruption permits reliable continuation. Their outcomes must concern usable work, consequential errors and total effort, including owner attention. These research questions create no product commitments or standing implementation backlog.

Controlled productivity, comparative error detection, professional suitability, portability and sustained adoption remain unestablished. The development record's reported improvements do not isolate causal effects from model capabilities, accumulated knowledge, work begun earlier or the owner's involvement. Activity counts cannot supply those missing comparisons.

8.7 Summary

Root's evidence supports a revisable environment in which sources, methods, relationships, authorization and continuing ownership can connect production to examination and correction. The strength of each finding remains bounded by its actual subject, source basis and checked path.

App and Piping expose operative and evaluative questions that Root alone cannot answer. Their findings can revise the common means through iterative feedback. Accountable human judgment remains situated engagement throughout that relation; neither implementation traces nor passing checks establish it on the person's behalf.