Specification

1. Scope

This Standard defines how a group of people delegates work to AI agents during a live, synchronous session — a meeting, a design review, a war room, a ward round, a trading desk huddle — without losing track of who is responsible for the result.

It is a standard of conduct, not a software interface. It specifies what participants say, in what order, and what each utterance commits them to. It does not specify a wire format between machines, a model, a vendor, or a user interface. Conformance Level 3 (Section 10) additionally defines an event record so that sessions can be instrumented, but Levels 1 and 2 require no software at all.

1.1 What this Standard is not

• It is not an agent-to-agent protocol. See Section 3.
• It does not govern what an agent is permitted to do, what data it may access, or how it is secured. Those concerns belong to an organization's own policies.
• It does not replace professional judgment, licensure obligations, or any legal duty. Section 9 exists to protect those obligations, not to substitute for them.
• It is not a meeting format, and it does not require one. See Section 1.2.

1.2 It does not make meetings formal

A reasonable first impression of this document is that it would turn every conversation into a stilted exchange of call signs. It should not, and a room that experiences it that way has adopted it wrongly.

The Standard governs what happens when work is delegated to an agent, which in most meetings is a small fraction of the time. Everything else — the digression, the argument, the joke that keeps people willing to attend — is untouched, and is not the Standard's business.

It applies equally to a tightly agenda-driven session and an open-ended exploratory one. The difference between those two is an agenda, not a protocol. An unstructured session arguably benefits more: it is where good ideas are most likely to be raised, agreed to enthusiastically, and then lost entirely because nobody ever owned one.

A room MAY decide a given session is not one where anybody will drive an agent, and simply not use the loop. That is not a conformance failure; conformance is claimed per session, and a session with no delegated work has nothing to conform about.

2. Terminology

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119 and RFC 8174, when and only when they appear in all capitals.

Defined terms appear in spec/glossary.md.

3. Motivation

Existing protocols in this space describe machines talking to machines. Model Context Protocol connects an agent to tools. Agent-to-agent protocols connect agents to each other. Open Floor Protocol arbitrates turn-taking between conversational agents.

None of them describe the layer where the risk actually concentrates: several qualified humans, in one room, each driving their own agents, talking to each other.

That layer has a specific failure mode. When someone says "I'll look into that" and starts typing into an agent, the room loses the ability to answer four questions:

1. Who heard the request?
2. Who turned it into a prompt, and what did that prompt actually say?
3. Who is watching the work?
4. Who is accountable for deciding whether the output is correct?

Agents produce a large amount of motion very quickly. Without an answer to those four questions, motion is not progress — it is unattributed work product arriving in a professional setting where somebody's licence, signature, or fiduciary duty is attached to the outcome.

This Standard exists to keep those four questions answerable at every moment of a session.

4. Relationship to prior practice

This Standard extends principles from established practices in high-reliability fields. It is not endorsed by, affiliated with, or evaluated by any of the organizations named below, and the evidence supporting those practices does not transfer to this Standard.

• Closed-loop communication, originating in military radio procedure: a sender transmits, the receiver acknowledges and repeats the message back, and the sender confirms the readback is correct. The Claim beat (Section 6.2) is a direct application of this three-step pattern.
• Crew Resource Management in aviation, and its adaptation into healthcare as team-training programs that formalize call-outs (announcing critical information to the whole team while directing responsibility to a named individual) and check-backs (the receiver repeating information to confirm it was understood).
• Structured clinical handoff tools, which treat a handoff as the transfer of information together with authority and responsibility, and which hold that the sender remains accountable until the receiver has explicitly acknowledged acceptance. Several such tools require a synthesis step in which the receiver restates what they heard.
• Deliberative assembly procedure, which establishes that a motion must be stated, seconded, and disposed of — never left ambiguous.

The contribution of this Standard is not the discovery of these patterns. It is their application to a case none of them anticipated: a delegate that is not a person, that works invisibly, that produces confident output at speed, and that has no professional accountability of its own.

4.1 Relationship to research on co-prompting

The term co-prompting (equivalently, collaborative prompting) is established in the human-computer interaction literature, where it is defined as a process involving the sharing and discussion of prompts for generative AI systems among two or more individuals. Prior work has studied tooling to support collaborative prompt authoring, and has documented the awareness and communication costs that arise when collaborators cannot see each other's prompts.

This Standard does not claim to originate the term or the practice. It addresses a different question: given that people already co-prompt, what conduct makes co-prompting accountable in a professional setting?

See spec/background.md for citations.

5. Roles

A role is a position held with respect to one task. The same person will hold different roles for different tasks in the same session, often simultaneously.

Role	Definition
Caller	The participant who raises a task. Any participant MAY be a Caller.
Listener	A participant capable of owning the task, who must acknowledge before the task is described.
Owner	The single participant accountable for the agent work on a task from Claim until a terminal state.
Contributor	Any participant who supplies context to the Owner's prompt.

5.1 The Owner closes their own task

There is deliberately no separate approver role. The participant who owns a task is the one who closes it, states the disposition, and carries the consequence of that judgment.

This Standard does not decide who is qualified to accept professional work. Every regulated profession has already settled that — engineer of record, attorney of record, engagement partner, attending physician — and a protocol that restated it would either duplicate that law or contradict it.

Where a domain requires a second person to approve a result before anyone relies on it, its profile says so (Section 11). Where a firm imposes a stricter internal standard of care, that is a matter for the firm. The core's job is narrower and more useful: make it unambiguous, at every moment, who owns which task and what they decided.

6. The session loop

The loop has four beats and ten states. The beats exist so the loop can be taught and spoken. The states exist so it can be specified and instrumented.

One further state, STATUS, sits outside the loop entirely: it concerns the session rather than any single task. It is defined in Section 6.5.

CALL ─→ ACKNOWLEDGE ─→ DESCRIBE ─→ [CLARIFY] ─→ CLAIM ─→ PROMPT ─→ [AUGMENT] ─→ RUN ─→ RETURN ─→ CLOSE
└────────────── Call ──────────────┘            └ Claim ┘  └──── Co-prompt ────┘  └──────── Close ────────┘

Square brackets denote OPTIONAL states.

6.1 Beat one — Call

CALL — The Caller utters a call type from the active profile's vocabulary and then stops speaking. The Caller MUST NOT describe the task in the same utterance.

The purpose of the pause is to let participants who are mid-prompt reach a stopping point before information they are accountable for hearing is spoken.

ACKNOWLEDGE — Each Listener utters an acknowledgement.

An acknowledgement asserts attention, not comprehension. At this point nothing has been described: the only utterance so far is the call type. A Listener is saying "I have stopped what I was doing and you may proceed", which is why the cue is "Ready" rather than any word implying receipt of content. There is nothing yet to have received.

• The Caller MUST NOT proceed to DESCRIBE until every Listener has acknowledged.
• If no Listener acknowledges within a reasonable interval, the Caller SHOULD re-issue the CALL.

Acknowledging in two steps

A Listener who is mid-thought is in an awkward position: they are not ready, but saying nothing is indistinguishable from not listening. Such a Listener SHOULD utter heard, and then ready once they have actually stopped.

Caller: Coordination. First Listener: Ready. Second Listener: Heard — one moment. (a few seconds) Second Listener: Ready. Caller: The tenant is adding a solid-fuel smoker …

"Heard" is not an acknowledgement. It is a promise of one, and the Caller MUST still wait for "Ready" from that Listener before describing.

The distinction is exact rather than stylistic. "Heard" confirms receipt of the call, which genuinely was uttered. "Ready" asserts availability for the description, which has not been uttered yet. Both are true statements at that moment, and they are true about different things — which is why a room needs both words and why neither can stand in for the other.

Without this, a Listener who needs ten seconds has only bad options: claim a readiness they do not have, or stay silent and be read as inattentive. That silence is the failure this beat exists to prevent, so the Standard has to give it somewhere to go.

DESCRIBE — The Caller states the task in one or two sentences: what must be determined, and where. The Caller then stops speaking.

The description SHOULD identify the subject matter and its location precisely enough that a Listener could restate it. It SHOULD NOT include a proposed solution unless the Caller intends to constrain the approach.

CLARIFY (OPTIONAL) — Any Listener MAY ask a clarifying question before any participant claims the task.

• A clarifying question MUST NOT be interpreted as a claim.
• A Listener asking for clarification SHOULD mark it as such, so the room does not mistake the question for ownership.

6.2 Beat two — Claim

CLAIM — One Listener takes ownership and becomes the Owner.

• A CLAIM MUST include a restatement of the task in the claimant's own words. A claim without a restatement is not a valid claim.
• A CLAIM MUST identify the claimant, by name or by unambiguous voice recognition among the participants.
• From a valid CLAIM until a terminal state, the task MUST have exactly one Owner.

The restatement is the load-bearing element of this beat. It is the only point in the loop where the Caller can detect that the task was misheard, and it is cheap relative to the cost of discovering the error after an agent has run.

The name and the claim are normally one utterance rather than two:

Developer A: Heard — lock the title height so Open and For You stop pushing the cards. Developer A, on it.

Contention. If two participants claim simultaneously, the first unambiguous claim prevails and the other participant MUST withdraw. Contention MUST be resolved before PROMPT. Participants MUST NOT debate the merits of the assignment during the loop; a reassignment is a new CALL.

Prior ownership. If the task is already owned from earlier in the session, the existing Owner MUST say so and report status instead. The loop MUST NOT be re-run for a task that is already owned.

6.3 Beat three — Co-prompt

PROMPT — The Owner utters the prompt aloud before submitting it to an agent.

• The Owner MUST utter the prompt aloud before RUN, at every conformance level.
• The utterance SHOULD convey what the agent is being asked to investigate, against what inputs, and what form the answer should take. It need not be read verbatim.
• Where a prompt is too long to speak in full, the Owner MUST speak a faithful summary and MAY supply the remainder in writing. Omitting the spoken summary is a conformance failure.

This is required at every level, including the entry level, because speaking to the agent is the interface rather than a performance for the room. A session in which people dictate to their agents produces an audible prompt as a side effect of how the work is done; a session in which nobody ever hears anyone else's prompt is not practising this Standard in any meaningful sense.

Announcing that work is underway is not a substitute for this state. "I'm on it" conveys nothing that lets the room correct a misunderstanding. The purpose of PROMPT is to expose the Owner's interpretation while it is still cheap to change.

The room holds new calls while a prompt is being spoken. From the utterance of prompting until finished, participants SHOULD NOT open a new CALL.

A prompt is composed while it is spoken, and hearing a fresh call land mid-sentence is enough to lose it. The cost of waiting is a few seconds; the cost of not waiting is paid by the person least able to absorb it. finished exists so the room knows the floor is free again without having to guess.

A participant who cannot wait SHOULD utter a hold rather than a call, so the Owner knows something is queued without being handed it yet.

This is the one place hold is used. It is a different act from heard: nothing has been addressed to you, so there is nothing to confirm receipt of. You are reserving a turn, not answering one.

AUGMENT (OPTIONAL) — Any participant MAY supply additional context after hearing the prompt and before the agent runs.

The normal way to do this is proxy prompting: the contributor asks for the floor, the Owner grants it, and the contributor speaks the addition into the Owner's agent directly.

Contributor: Adder. Owner: Go ahead. Contributor: The ceiling below the kitchen is already tight.

This is not a courtesy. It is what makes invariant 5 self-enforcing: the whole room hears the addition go in, so nobody has to be told afterwards whether it was included. An earlier draft required the Owner to answer each augmentation with a word confirming inclusion, which existed only because the revised prompt was never uttered again. Handing over the floor removes the gap instead of reporting on it.

• The Owner MUST grant or refuse the floor audibly. Silence is a conformance failure.
• A refusal MUST state a reason. "Not adding — the study is above the slab" closes the loop; saying nothing does not.
• Cost is a legitimate reason. An addition can change what a task costs by an order of magnitude, and the Owner is the participant who carries that. "I can add it, but that takes this from a seventy-dollar question to a two-thousand-dollar one — do you want it?" is a conforming refusal, and it hands the decision back to the person asking rather than absorbing it silently.
• Where the Owner instead types the addition, or edits the prompt silently for any reason, the change MUST be spoken before RUN. What runs is what the room heard.
• Augmentations offered after RUN SHOULD trigger a re-prompt where the cost of restarting is lower than the cost of an answer built on an incorrect premise.

Ownership does not move. The Owner granted the floor, may cut it off at any point, corrects anything they disagree with, and still closes the task. A contributor speaking into an agent is not a second Owner, and invariant 1 is untouched.

Any participant may contribute, including participants who are not eligible to own the task.

6.4 Beat four — Close

RUN — The Owner submits the prompt and the agent begins work. The session continues; the room does not wait.

The Owner remains accountable for monitoring the work. Other participants MUST NOT direct new tasks at the Owner until the Owner has reached a terminal state or has explicitly parked the task.

Follow-up prompts are not separately governed. Real agent work is iterative: the Owner will refine, correct, and re-prompt several times before the answer is worth reporting. The Standard requires the opening prompt to be spoken, because that is where the room can still catch a misunderstanding cheaply. It does not require narrating the rest.

What the record captures is the task, its Owner, what it was for, and how it ended — not every utterance in the chain. A Standard that demanded otherwise would make the loop unusable in exactly the sessions it was written for.

RETURN — The Owner reports the result to the room.

The report MUST state what the agent produced and MUST distinguish it from what has been verified. A result that has not yet been closed MUST be labelled as preliminary when reported.

CLOSE — The Owner states the disposition.

• Agent output MUST NOT be treated as an outcome, relied upon, transmitted to a client, or incorporated into a work product until the Owner has closed the task.
• Where the active profile requires approval before reliance (Section 11), that approval MUST be recorded before the result is relied upon.
• The disposition MUST be one of the terminal states in Section 8 and MUST be stated audibly.

Where the profile defines a verification step, the participant who asked for the check answers it audibly — "Working" or "Still broken" — before the task can be closed Accepted. An unanswered check is an open task, not a finished one.

6.5 Status — outside the loop

Everything above concerns a single task. STATUS is the one state that does not.

STATUS — Any participant MAY call for status at any point in a session. Every Owner holding an open task MUST answer.

Anyone: Status. An Owner: Mati reporting. The double-click fix is up for review. Still running: the agent indicator upgrades.

• Any participant MAY call it. It is not reserved to a chair, a lead, or the person who called the original task.
• It MAY be called at any time. It is not an end-of-session ritual, and a session may contain several.
• Every Owner holding a task that has not reached a terminal state MUST respond, naming each task and where it stands.
• An Owner holding nothing says so. "Nothing open" is an answer; silence is not.
• A Status call changes nothing. It does not transfer ownership, does not close anything, does not oblige anyone to stop working, and is not a request for justification.

Why the Standard needs this. Invariant 8 requires every claimed task to reach a terminal state, but nothing else in the loop says when the room finds out whether that happened. Without STATUS, a task quietly abandoned at RUN is discovered after the session, if at all — which is precisely the failure the Standard exists to prevent, reintroduced at the session level.

It also answers a question the per-task loop cannot: what is running right now? In a room where several people are each driving agents, that is not a management question. It is the difference between a room that knows what it is waiting on and a room that has lost count.

6.6 Direct delegation

Not every task needs the floor. Where the Caller already knows who should own something, they MAY name that participant instead of opening the loop to the room:

Caller: Midhun — code. Is a fire damper required where that duct crosses the corridor wall? Midhun: Heard — check whether the corridor wall rating forces a damper at that penetration. Midhun, on it.

• The Caller MUST name the participant before the call type, so the room knows immediately that it is not being asked to acknowledge.
• The Caller MAY describe the task in the same utterance. The separation of CALL from DESCRIBE exists so that a room is not described at before it is listening; naming one person achieves that directly, so the pause has nothing left to protect.
• No separate acknowledgement is required. The named participant's CLAIM serves as it. A participant who is not ready SHOULD say heard first, exactly as in Section 6.1, and the Caller waits.
• Every other rule is unchanged. The named participant still restates, still speaks the prompt aloud, still closes the task, and remains the single Owner.

The named participant MAY answer directly without claiming, where they already know and no agent work is needed. That is a complete and conforming outcome: the loop exists to place accountability, not to force a task into an agent.

A named participant who is not the right owner SHOULD say so and pass, which returns the task to the room as an ordinary CALL. Direct delegation is a shortcut through CALL and ACKNOWLEDGE, not a way to assign work to someone who cannot take it.

Why this is in the Standard rather than left to habit. Without it, a room practising the loop has only two options for a question aimed at one person: open the floor and make everybody stop for something that concerns one of them, or step outside the protocol entirely and lose the record. The first is the reason people abandon protocols as bureaucratic; the second is the reason the record has holes.

6.7 Sessions where not everyone is following the Standard

Most rooms will contain people who have never heard of this document and are not going to read it. Client meetings, owner-architect-contractor sessions, and calls with counterparties are the normal case, not the exception.

A participant who is following the Standard MAY bring an outsider's question into the loop on their behalf, by restating it as a call and confirming the restatement back:

Owner's representative: Why do we have the dedicated outdoor air unit again? MEP engineer: Decision question — Mark is asking how we landed on the DOAS. Prompting now: search the design log and the value-engineering correspondence for when the DOAS was selected and what alternatives were priced. Mark, does that sound right? Owner's representative: Yep. MEP engineer: Running.

• The restatement MUST be confirmed by the person whose question it was, in their own words, before the result is relied upon. This is the CLAIM restatement rule applied across the protocol boundary.
• The participant who restates becomes the Owner. Accountability does not attach to someone who never agreed to it.
• Nothing may be attributed to the outsider that they did not say. "Mark is asking how we landed on the DOAS" is a claim about Mark, and confirming it is what makes it safe to record.

This inverts the usual burden, deliberately. Elsewhere the Standard asks the person raising a task to follow the protocol; here the person answering carries it, because the outsider owes nothing. A room that cannot do this can only practise the Standard in private, which would make it useless in exactly the meetings where accountability matters most.

7. Vocabulary

The loop in Section 6 describes what must happen. This section names what people actually say.

Every cue below is a spoken phrase bound to a state or an invariant. They are listed here, in the core, rather than in individual profiles, because they mean the same thing in every domain.

7.1 The cue registry

The requirement level of a cue is the requirement level of the behavior it carries. A MUST cue is not a stylistic preference — omitting the utterance means the invariant it serves was not satisfied.

The registry is grouped by where in the loop you would say it, which is the order somebody learning it will meet them. 🔒 marks a locked cue, which no profile may rename; see Section 7.3.

Beat one — Call

Cue	Default phrase	Carries	Level
acknowledge	"Ready" 🔒	ACKNOWLEDGE; invariant 2	MUST
heard	"Heard …"	receipt, at ACKNOWLEDGE or CLAIM	SHOULD
clarify	"Clarify: …"	CLARIFY	MAY

Beat two — Claim

Cue	Default phrase	Carries	Level
claim	"On it"	CLAIM; invariants 1 and 3	MUST
already_owned	"Already mine"	prior ownership	SHOULD
pass	"Pass"	contention at CLAIM	SHOULD

Beat three — Co-prompt

Cue	Default phrase	Carries	Level
prompting	"Prompting now"	PROMPT; invariant 4	MUST
go_ahead	"Go ahead"	grants the floor at AUGMENT	MUST
declined	"Not adding — …"	refusal at AUGMENT; invariant 5	MUST
finished	"Finished"	end of PROMPT; Section 6.3	SHOULD
adder	"Adder"	requests the floor at AUGMENT	SHOULD
hold	"Hold"	queued during PROMPT; Section 6.3	SHOULD
files_first	"Files first"	before PROMPT	SHOULD
propose	"I propose …"	before PROMPT	MAY
augment	"Add: …"	AUGMENT	MAY
handoff_offer	"Yours"	AUGMENT, across disciplines	MAY

Beat four — Close

Cue	Default phrase	Carries	Level
preliminary	"Preliminary"	RETURN; Section 9.1	MUST
working	"Working"	reply to a check	MUST
still_broken	"Still broken"	reply to a check	MUST
accepted	"Good"	CLOSE; invariant 8	MUST
rejected	"No good"	CLOSE; invariant 8	MUST
parked	"Parked — waiting on …"	CLOSE; invariant 8	MUST
dropped	"Dropped — covered by …"	CLOSE; invariant 8	MUST
return	"Back with …"	RETURN	SHOULD
out_of_scope	"Out of scope"	Section 9.2	SHOULD
running	"Running"	RUN	MAY
check	"Check: …"	after RETURN	MAY

Outside the loop

Cue	Default phrase	Carries	Level
reporting	"… reporting"	STATUS; invariant 6	MUST
status	"Status"	STATUS	MAY

Every phrase here was chosen against one test: is it already in somebody's mouth? A required phrase that people will not say is worse than no phrase, because it teaches the room that the document was written by someone who has never been in it.

Most of this registry is not designed. It is transcribed from the session in which practitioners worked the loop out loud, and where a word here differs from what that room said, the difference is a defect. Five deserve emphasis.

acknowledge is "Ready" and is locked. It asserts availability, and it is the only cue that releases the Caller to describe.

Version 0.3 made "Heard" the acknowledgement outright, and version 0.5 reversed that, correctly: as the sole acknowledgement it claimed receipt of a message that had not been sent. That correction stands. What it did not anticipate is a Listener who wants to confirm the call while declining readiness — a different act, and a legitimate one. heard now covers it, without ever substituting for ready.

heard confirms receipt of something that genuinely was said. It appears in two places, and what follows tells them apart:

• At ACKNOWLEDGE — "Heard — one moment." Receipt of the call, plus an explicit statement that you are not ready. See Section 6.1.
• At CLAIM — "Heard — lock the title height so the cards stop moving. On it." Receipt of the description, leading into the restatement.

Both are the same act pointed at different content. It is SHOULD rather than MUST because a Listener who simply takes two seconds and then says "Ready" has broken nothing; the cue exists so that taking those seconds is a recognised move rather than an awkward silence.

declined is MUST for the same reason go_ahead is. When someone offers a constraint and the Owner says nothing, the contributor reasonably believes it was included. Silence is the failure mode, and only silence violates invariant 5 — either handing over the floor or refusing out loud satisfies it.

preliminary is MUST because an unlabelled result becomes a commitment the moment someone outside the professional relationship repeats it. It is the most formal word that survives in this registry, kept because no shorter word carries the same protection. A profile MAY substitute a shorter one its people already use.

It is not the same as propose, and readers have confused the two. The difference is when they are spoken and what they are about:

propose — before the prompt, about the approach: "I propose we check the corridor rating first, then the damper schedule." preliminary — after the prompt, about the result: "Preliminary: the shaft works if the smoker sits right of the supply duct. That needs my review against the cut sheet before anyone builds to it."

One offers a plan the room can argue with while it is still cheap. The other attaches a warning to an answer that already exists, so nobody repeats it as settled.

claim is "On it". Earlier drafts used "Mine", chosen because it asserts exclusivity in a way that survives two people both being on something. That reasoning was sound and the word still failed the test every cue here is judged against: practitioners disliked saying it, in two separate recorded sessions, and a required phrase people avoid is worse than no phrase.

Exclusivity is carried instead by the surrounding rules, which is where it belonged: invariant 1 permits exactly one Owner, and contention is resolved before PROMPT rather than by the choice of word. Pairing the claim with the claimant's name — "Kenny, on it" — does the rest, and satisfies the naming requirement in the same breath.

7.2 Universal call types

A call type opens the loop. Most are domain-specific and belong in a profile, but one is universal:

Call type	When
Question	A decision is unknown and blocks progress. May resolve with no agent work at all.

Every profile inherits Question. A profile MUST NOT redefine it and MUST NOT declare a call type of the same name.

This list is deliberately short. A term is promoted to universal only once independent profiles have converged on it in practice — not because it seems like every industry ought to have one.

Call types are written as short nouns. How they are spoken is governed by Section 7.2.1, which is more forgiving.

7.2.1 Saying a call type

Nobody says a bare noun and stops. In practice people pad it, and the Standard accepts the padding rather than fighting it.

The suffix rule. Any call type MAY be spoken with question, study, or analysis appended, and it opens the loop identically. "Code", "code question", and "code study" are the same call. So are "load" and "load analysis".

This is transcribed rather than invented — all three forms appear throughout the recordings this Standard was built from. It also keeps written call types short without forcing every profile to enumerate the same three variants for every entry.

Aliases. A profile MAY declare aliases for a call type where its domain genuinely uses a different word for the same thing. A Drawings call might alias plans and specifications; the choice between those words is regional and personal, and none of them is more correct.

An alias:

• MUST open the same loop and mean the same thing. It is a synonym, not a variant with different scope.
• MUST NOT collide with another call type, another alias, or a suffix-rule form of either. The validator rejects collisions, because a word that could open two different calls opens neither reliably.
• SHOULD be a word the domain already uses, on the same evidence standard as everything else here.

Recognising calls in a transcript. A Level 3 implementation matching call types against speech SHOULD prefer the longest form it finds. "Code question" is a far safer signal than "code", which occurs constantly in ordinary engineering conversation without opening anything.

7.3 Dialects

A profile MAY substitute the phrase for any unlocked cue where its domain genuinely says something else.

A substitution:

• MUST keep the cue's meaning and its requirement level
• MUST be declared in the profile's cueDialect so the substitution is documented rather than folklore
• MUST NOT remove the cue or make it optional
• MUST NOT name a locked cue
• SHOULD be drawn from a recording of the domain's own sessions, not from the author's sense of what sounds right

Locked cues

A locked cue MUST NOT be substituted by any profile. acknowledge is the only one.

Every other cue is spoken by one person at a time, so a local accent costs nothing. The acknowledgement is different: it is the single utterance the whole room produces in answer to the same trigger, and it is the first thing anyone hears when they join a session. It has to survive somebody from another profession walking into the meeting.

No published profile is constrained by this. Version 0.5 removed the only two substitutions ever declared, both in the AEC profile, after checking the recording they claimed to come from and finding neither phrase in it.

That is worth stating rather than hiding, because it means the dialect mechanism currently has no users. It stays because the two founding profiles were written from different rooms and the possibility of a genuine local word is real — but the first profile to declare a dialect should expect to be asked where it was recorded.

A profile that declares no dialect uses the default phrases. Most profiles should need no dialect at all; a long dialect block usually means the author is renaming for taste rather than recording how their people already speak.

8. Terminal states

Every claimed task MUST reach exactly one terminal state before the session ends.

State	Meaning
Accepted	The Owner accepts the output. It may be relied upon within the limits the Owner states, and subject to any approval the profile requires.
Rejected	The output is not acceptable. The task is closed. A further attempt is a new CALL.
Parked	Progress is blocked by a dependency outside the session. A Parked task MUST name the blocker and the party responsible for clearing it.
Dropped	The task was overtaken by another task or by a decision that made it moot. The task that covers it MUST be identified.

A task that is silently abandoned has not reached a terminal state and is a conformance failure. This includes discarding an unsatisfactory agent result without saying so: an undisclosed discard is indistinguishable from work never attempted, and the question will return.

9. Accountability invariants

These invariants are the substance of the Standard. A session that follows the vocabulary but violates an invariant does not conform.

1. Single ownership. A task MUST have exactly one Owner from CLAIM until a terminal state. Ownership MUST NOT be shared, implied, or assumed.
2. Acknowledged attention. The Caller MUST NOT DESCRIBE until every Listener has acknowledged.
3. Restatement on claim. A CLAIM MUST include a restatement of the task.
4. Audible prompt. The prompt MUST be uttered aloud before RUN, at every conformance level.
5. What runs is what the room heard. Where the prompt changes after it was uttered, the change MUST be spoken before RUN — either by the contributor who was granted the floor, or by the Owner. An addition the Owner declines MUST be refused aloud, with a reason. Silence is the failure mode.
6. Answered status. A STATUS call MUST be answered by every Owner holding a task that has not reached a terminal state.
7. Closure before reliance. Agent output MUST NOT be treated as an outcome until the Owner closes the task with a disposition. Where the active profile requires approval before reliance, that approval MUST be recorded first.
8. Explicit disposition. Every claimed task MUST reach exactly one terminal state, stated audibly.
9. No silent transfer. Ownership transfers only by an explicit statement from the current Owner and an explicit acceptance by the new Owner. An Owner remains accountable until that acceptance occurs.

9.1 Preliminary results

A result that has not been closed MUST be labelled preliminary whenever it is spoken, and MUST NOT be presented to a client, counterparty, or authority as a finding.

This invariant exists because an unlabelled agent output becomes a commitment the moment someone outside the professional relationship repeats it. The label is cheap. Withdrawing a number a client has already acted on is not.

9.2 Scope boundaries

Where a called task falls outside the scope of the engagement under which the session is being conducted, a participant SHOULD say so during the loop rather than absorbing the work silently. This Standard takes no position on how such work is authorized; it requires only that the boundary be named while everyone is present.

10. Conformance

Conformance is claimed per session, not per organization. See spec/conformance.md for full requirements.

Level	Name	Summary
L1	Spoken	The loop is followed verbally, prompts included. No record is required.
L2	Recorded	Additionally, every claimed task has a durable record of its Owner and terminal state.
L3	Instrumented	Additionally, the session emits machine-readable events conforming to schema/session-event.schema.json.

The split is: L1 is how you speak, L2 is what you keep. Uttering the prompt aloud moved into L1 in version 0.5, because a room where nobody hears anyone else's prompt is not practising this Standard regardless of how good its records are.

11. Profiles

A profile adapts this Standard to a domain by supplying vocabulary and accountability rules. A profile MUST conform to schema/profile.schema.json and MUST NOT weaken any invariant in Section 9.

A profile declares:

• callTypes — call types ADDITIONAL to the universal ones in Section 7.2
• ownerEligibility — who may own each call type
• cueDialect — OPTIONAL phrase substitutions (Section 7.3)
• approval — OPTIONAL. Whether someone other than the Owner must approve a result before anyone relies on it, and who that is
• additionalStates — OPTIONAL additional REQUIRED states, such as a formal sign-off
• retention — what MUST be recorded and for how long

Profiles MAY add states, add vocabulary, and tighten requirements. Profiles MUST NOT remove states, remove invariants, or lower a requirement level from MUST to SHOULD.

11.1 Approval

Most domains need no approval block: the Owner closes the task and that is the end of it.

Declare one where a profession or jurisdiction requires a named person to accept the result before anyone relies on it — a design professional in responsible charge, an attorney of record, an engagement partner. The profile names that person in its own domain's language, because this Standard has no vocabulary for professional responsibility and should not invent one.

Where a licensing body designates who holds responsible charge, the profile MUST NOT designate anyone else.

An approval requirement does not move ownership. The Owner still closes the task and still states the disposition; the approval is an additional gate on reliance, recorded before the result leaves the room as a finding.

Published profiles live in profiles/. To write one, see profiles/WRITING-A-PROFILE.md.

12. Versioning

This Standard uses MAJOR.MINOR versioning, documented in VERSIONING.md. Version 0.x is a draft; breaking changes may occur in any release. A conformance claim MUST cite the version it was assessed against.

13. Citation

The Open Co-Prompting Standard, Version 0.6 (Draft). https://co-prompting.com