Evidence and Acceptance

Evidence and acceptance

A result is useful only when its source, execution conditions, and scope are clear. Keep a successful check, a product outcome, and a maintainer's acceptance as separate facts.

Record the claim and its limits

Each verification record identifies:

• The claim and completion condition being checked.
• Source repository, exact commit, component path where relevant, and artifact identities.
• The person or agent that executed the commands, the named execution environment, whose request authorized the work, and who accepted the result.
• Inputs, commands, outputs, return codes, failures, and evidence inventory or hashes.
• Simulation or physical scope, load and fault conditions, and what remains unverified.
• The acceptance decision, its author and date, or an explicit pending/rejected state.

Keep credentials, private endpoints, personal host paths, and other sensitive configuration out of public records. Use public artifact identifiers and a documented restricted-evidence reference when the underlying material cannot be published.

Evidence levels

Record	Supports	Does not establish by itself
Static source inspection	Structure, declared rules, and identifiable code paths.	Runtime behavior or deployment readiness.
CI/unit tests	The checks run against the identified revision.	Semantic completeness, independent acceptance, or physical safety.
Simulation integration	Behavior under the recorded simulation, load, and fault conditions.	Physical device support or arbitrary-load reliability.
Native effects and receipts	Their own observed facts and correlation with the original identity.	Authority or completion beyond their declared scope.
Explicit acceptance	Acceptance of the named output and stated scope by the authorized maintainer.	General approval of other versions, scenarios, or unresolved failures.

Package verification, registration, review, qualification, activation, and execution are separate stages. A repository or SDK migration does not collapse them.

CP2: two records, two scopes

The merged baseline contains a successful CP2 precheck and acceptance handoff. That record explicitly did not establish user acceptance.

A later CP2 acceptance-failure diagnosis, preserved at its original commit and subsequently published unchanged through rx_docs #118, records the rejected acceptance run. Its accompanying cost and status record, section 24 records CP2 not accepted, CP3 not started, and the retained UNKNOWN/resource hold. The precheck remains historical evidence; it is not relabeled as acceptance.

These are source records, not a live inspection of the preserved environment. Migration work does not modify that environment. Preserve the original Run, request, operation, invocation, evidence, resource hold, and recorded environment changes. SEND_ENTERED is not native-entry proof. Missing completion evidence must not be converted into NO_EFFECT, permission to replay, or resource release.

Storage and citation

Successful, failed, rejected, UNKNOWN and historical source records belong in rx_docs, with immutable commit/path links. Current canonical documentation and semantic contracts are now in RobotTransformation after M4 verification. The evidence charter defines intake and preservation. The wiki links to those records; it does not become an evidence archive or normative source.

When a document moves, retain its original citation and record the new current location separately. A checksum proves content consistency; publisher authenticity, execution authority, and acceptance require their own evidence.

Closing a delivery item

Use Acceptance = Pending for a required checkpoint until the maintainer decides. Rejection preserves the submitted attempt and the reason. A subsequent attempt gets its own evidence record while retaining the original uncertain runtime identity wherever recovery rules require it.

Mark Status = Done only after the scoped output, required checks, and required acceptance are complete. A planning deliverable may finish while its implementation remains Backlog or Ready. Physical equipment operation is not authorized by migration acceptance.