Conformance Model

This section defines the candidate conformance model for future aws2 profiles. It is not active as a public conformance scheme in this working draft. The current working form is a profile-first crosswalk and evidence model, not a conformance program.

5.1 Current Conformance Status

No system can currently claim public conformance to aws2.

The working draft may be used for internal review, design alignment, pilot assessment, crosswalk planning, and evidence experiments. Any such use must describe the scope, identify that the document is a non-released profile-first draft, and use conservative claim language.

5.2 Assessment Object

A future aws2 conformance model, if one is created, should apply to a scoped agentic workspace system, not to an organization in the abstract and not to a standalone model, repository, skill, runtime, or product unless that component is the entire defined boundary.

A claim or assessment should identify:

• the system boundary
• the assurance level or profile being evaluated
• the applicable control families
• the control owners
• inherited controls
• evidence artifacts reviewed
• exclusions and rationale
• validation method, if any

5.3 Applicability

Each candidate requirement should have one applicability state for the scoped system:

• applicable
• not applicable with rationale
• inherited from another control owner
• not evaluated in the current review

Applicability must be justified by the system boundary. A system should not exclude a requirement solely because the requirement is inconvenient or owned by a different team.

5.4 Implementation State

Each applicable candidate requirement should have one implementation state:

• implemented
• partially implemented
• planned
• not implemented
• implementation state not evaluated

Implementation state describes whether the control behavior exists. It does not by itself prove that the behavior operated effectively.

5.5 Evidence State

Each applicable candidate requirement should have one evidence state:

• evidence available
• evidence partial
• evidence unavailable
• evidence not required for draft review
• evidence state not evaluated

Evidence state describes whether a reviewer can inspect durable proof for the control. It does not by itself prove control sufficiency or external compliance.

5.6 Inherited Controls

A scoped system may inherit controls from another owner, such as an endpoint management program, runtime vendor, identity provider, logging pipeline, or organizational risk process.

Inherited controls should identify:

• the inherited control source
• the owner responsible for operating it
• the evidence artifact that supports inheritance
• any assumptions or limitations
• the impact if the inherited control is unavailable

5.7 Minimum Working-Draft Assessment Record

A working-draft assessment record should include:

• scope record
• assurance level target, if any
• candidate control-family applicability
• implementation state for reviewed controls
• evidence state for reviewed controls
• inherited controls and assumptions
• exceptions, planned remediation, or risk acceptance
• claim-limit statement

5.8 Future Conformance Profiles

A future released aws2 version may define conformance profiles. A profile should specify:

• required control families
• required levels
• applicability rules
• acceptable inherited controls
• minimum evidence artifacts
• review or validation method
• claim language
• expiry, reassessment, or versioning rules

Until such profiles exist, aws2 remains a profile-first candidate control, crosswalk, and evidence effort.