Conformance

This document is normative. Terminology follows Core §2.

1. What conformance applies to

Conformance is claimed for a session, not for an organization, a product, or a person.

An organization MAY state that it runs sessions to a given level as a matter of policy. That is a description of practice, not a conformance claim. Only a session can conform, because only a session can be assessed.

A conformance claim MUST cite:

1. The level claimed (L1, L2, or L3)
2. The version of this Standard assessed against
3. The profile in effect, if any

Example: "This review was conducted at Co-Prompting L2, Standard v0.2, AEC profile."

2. Level 1 — Spoken

Intent: the loop is followed out loud. Nothing is written down. This level is achievable in any meeting, immediately, with no tooling.

To conform at L1, a session MUST satisfy all of the following:

1. Every task delegated to an agent begins with a CALL using a call type from the active profile.
2. The Caller does not DESCRIBE until every Listener has acknowledged.
3. Every claimed task has exactly one Owner, established by a CLAIM that includes a restatement.
4. Every augmentation offered before RUN is acknowledged aloud as incorporated or declined.
5. Agent output is not treated as an outcome until accepted by a qualified Adjudicator.
6. Every claimed task reaches exactly one terminal state, stated audibly.
7. Unadjudicated results are labelled preliminary whenever spoken.

At L1, the prompt SHOULD be uttered aloud. It is not required, because L1 is intended to be adoptable by a room with no recording and no shared screen.

3. Level 2 — Recorded

Intent: the session leaves a durable record sufficient to answer, after the fact, who owned each task and how it ended.

To conform at L2, a session MUST satisfy all L1 requirements, and additionally:

1. The prompt MUST be uttered aloud before RUN. Where the prompt is too long to speak in full, a faithful spoken summary satisfies this requirement; silent submission does not.
2. A durable record MUST exist for every claimed task, capturing at minimum:
   • the call type
   • a description of the task
   • the identity of the Owner
   • the terminal state
   • the identity of the Adjudicator, where the terminal state is Accepted or Rejected
   • the named blocker and responsible party, where the terminal state is Parked
3. The record MUST be retained for at least the period the active profile specifies. Where no profile is in effect, the record SHOULD be retained for the life of the engagement it relates to.
4. The record MUST be created during or promptly after the session, not reconstructed later from memory.

The record's medium is unconstrained. A shared document, a ticket per task, a whiteboard photograph with legible attribution, or an instrumented system all satisfy L2 provided the required fields are present and durable.

4. Level 3 — Instrumented

Intent: the session emits machine-readable events, so conformance can be verified mechanically rather than attested.

To conform at L3, a session MUST satisfy all L2 requirements, and additionally:

1. The session MUST emit an event stream conforming to schema/session-event.schema.json.
2. Every state transition in Core §6 that occurs MUST produce a corresponding event. OPTIONAL states produce events only when they occur.
3. Every event MUST carry a session identifier, a task identifier, a monotonic sequence number, a timestamp, and the identity of the participant whose utterance or action produced it.
4. The stream MUST be internally consistent. Specifically:
   • no describe event for a task precedes acknowledgements from all listeners recorded for that task
   • no claim event lacks a restatement field
   • no run event precedes a prompt event for the same task
   • every augment event is followed by an augment_response event from the Owner
   • every task with a claim event has exactly one terminal event
   • no task has two claim events without an intervening explicit transfer
5. The stream MUST be retained under the same retention requirement as the L2 record.

An implementation MAY derive events from an automated transcript. Derived events MUST be marked with derivation: "inferred" so that a verifier can distinguish them from events emitted by explicit user action.

4.1 Verification

A session's L3 conformance is verifiable by checking the event stream against the consistency rules in §4.4. A verifier SHOULD report each violated rule with the offending task identifier.

Conformance verification does not assess the quality of any prompt, result, or adjudication. It assesses only that the loop was followed and that accountability is traceable.

5. Partial conformance

There is no partial level. A session that satisfies six of the seven L1 requirements is non-conforming, not "L1 minus one."

A session MAY conform at different levels for different portions if the portions are clearly bounded and separately claimed. This SHOULD be avoided; it usually indicates the session should have been split.

6. What conformance does not mean

Conformance means the loop was followed and accountability is traceable. It does not mean:

• that any agent output was correct
• that any adjudication was competent
• that the work satisfies any professional, contractual, or regulatory obligation
• that any organization or individual is certified by anyone

This Standard has no certification body, no conformance mark, and no accreditation scheme. Claims are self-asserted. A claim that misrepresents a session is a misrepresentation by the claimant, not a failure of the Standard.

7. Reference implementation

An implementation is a reference implementation if it produces an L3-conforming event stream from real sessions and its output has been checked against the consistency rules in §4.4.

Implementations are listed in IMPLEMENTATIONS.md. Listing is descriptive and is not an endorsement.