Evidence Model

This section defines the first-pass aws2 evidence model. It is candidate normative text for the working draft. It does not create an audit program, certification package, or public conformance requirement.

Evidence in aws2 should answer six questions:

• what agentic workspace system is in scope
• what agents, tools, skills, connectors, identities, and resources were allowed to use
• what runtime policies, approvals, and boundaries were intended to control those actions
• what high-impact actions, denials, approvals, changes, and validations actually occurred
• who owned and reviewed the control decisions
• what claim limits apply to any mapping or assurance statement

Evidence should be durable, attributable, time-bounded, scoped, and reviewable without unnecessary exposure of secrets or confidential payloads.

9.1 Evidence Principles

The scoped agentic workspace system SHOULD prefer derived and reviewable evidence over raw operational content.

Derived evidence examples include:

• inventories
• manifests
• configuration snapshots
• permission declarations
• source and version records
• structured receipts
• validation reports
• owner matrices
• exception records
• redacted summaries
• hashes or stable references to private evidence stores

Raw secrets, live credentials, private keys, session cookies, confidential message contents, full customer records, and unrestricted session transcripts SHOULD NOT be used as ordinary aws2 evidence artifacts. If raw material must remain available for an authorized reviewer, the shared evidence packet should use a redacted summary, stable event identifier, hash, or private evidence reference instead.

9.2 Evidence Artifact Metadata

Each evidence artifact SHOULD identify:

• artifact title or identifier
• artifact type
• scoped system or boundary
• control family or families supported
• owner or evidence custodian
• creation date or collection period
• source system or source repository
• version, commit, configuration revision, or policy revision where applicable
• sensitivity and redaction state
• retention expectation
• known limitations or assumptions

Level 2 and Level 3 evidence SHOULD be reproducible from a system of record, or should explain why reproduction is not practical.

9.3 Evidence Families

aws2 recognizes six first-pass evidence families.

Inventory and scope evidence:

• supports AWS2-SCP, AWS2-DEL, AWS2-WSB, and AWS2-GOV
• identifies runtimes, tools, skills, skill sets, connectors, repositories, files, SaaS systems, identities, owners, approvers, evidence stores, and exclusions
• should name systems and categories without exporting the confidential contents of those systems

Configuration and policy evidence:

• supports AWS2-DEL, AWS2-WSB, AWS2-RUN, AWS2-CTX, and AWS2-SEC
• records what the system was configured or intended to allow, deny, gate, isolate, retain, or redact
• should expose policy structure and outcomes without exposing live tokens, credentials, or sensitive payload examples

Provenance and supply-chain evidence:

• supports AWS2-SRC, AWS2-SEC, AWS2-VAL, and AWS2-GOV
• records where skills, tools, connectors, prompts, scripts, packages, models, and helper services came from and how changes were reviewed
• may include source URLs, repository identifiers, commits, lockfiles, checksums, signatures, attestations, reviewer records, or update receipts

Runtime activity and approval evidence:

• supports AWS2-RUN, AWS2-DEL, AWS2-LOG, AWS2-SEC, and AWS2-VAL
• records high-impact action requests, approvals, denials, policy triggers, tool calls, connector use, shell execution, file writes, exports, rollback, cancellation, and emergency stop events where applicable
• should prefer event metadata, action classes, policy outcomes, scopes, timestamps, actors, and stable event identifiers over full raw payloads

Validation and assurance evidence:

• supports AWS2-VAL and may support every other family
• records whether controls were tested, inspected, sampled, reviewed, challenged, or accepted as a known gap
• may include validation plans, review checklists, policy test results, denied-action tests, boundary tests, red-team summaries, tabletop notes, findings, remediation trackers, and risk acceptance records

Governance and decision evidence:

• supports AWS2-GOV, AWS2-SCP, AWS2-DEL, and claim-language review
• records ownership, deployment decisions, review cadence, exceptions, risk acceptance, release decisions, training expectations, external mapping decisions, and claim limits
• should expose decision metadata, owner roles, and versioning without unnecessary personnel data or internal discussion content

9.4 Minimum Working-Draft Evidence Packet

For internal working-draft review, a scoped system SHOULD maintain a minimum evidence packet containing:

• scope record and inventory of runtimes, tools, skills, skill sets, connectors, identities, and connected resources
• owner matrix for workspace, runtime, source, governance, and evidence responsibilities
• runtime policy, approval policy, boundary configuration, or equivalent control description
• source and provenance record for trusted skills, tools, connectors, prompts, scripts, and dependencies
• sampled high-impact action, approval, denial, or policy-trigger receipts
• validation or review artifact for the assessed boundary
• exception, risk acceptance, and claim-limit record

This packet is intentionally lighter than a certification package. It is the minimum useful basis for an internal review, mapping exercise, or evidence experiment.

9.5 Evidence By Assurance Level

Level 1 evidence SHOULD show that the scoped system is named, bounded, owned, inventoried, and reviewed at least once.

Level 2 evidence SHOULD show repeatable production operation, including policy configuration, approval behavior, provenance records, retained receipts, validation results, exception handling, and owner review.

Level 3 evidence SHOULD show stronger integrity, independence, and reconstruction capability, including historical records, separated review, tamper-evident or independently retained logs where practical, recurring validation, high-impact workflow reconstruction, and reassessment triggers.

9.6 Evidence Quality States

When evaluating a candidate requirement, reviewers MAY use the following working-draft evidence quality states:

• evidence available: durable evidence exists and is reviewable for the stated scope and time period
• evidence partial: some evidence exists, but scope, integrity, attribution, redaction, retention, or completeness is limited
• evidence unavailable: no reviewable evidence exists for the stated requirement
• evidence not required for draft review: evidence was intentionally not requested for the current internal review
• evidence state not evaluated: the review did not assess evidence state

Evidence quality is not the same as control effectiveness. A complete evidence packet may still show that a control is weak, failed, or only partially implemented.

9.7 Evidence Redaction And Claim Limits

Evidence redaction MUST NOT hide facts that materially change the conclusion of a review. Redaction is acceptable when it protects secrets, credentials, personal data, confidential payloads, or unrelated business content while preserving enough metadata for control review.

An evidence packet supports a bounded statement only for the scoped system, time period, control families, and artifacts reviewed. It does not prove full aws2 conformance, legal compliance, external-framework coverage, or system security unless a future released profile defines those conditions.