The Open Co-Prompting Standard

A profile adapts The Open Co-Prompting Standard to one domain. The loop does not change. What changes is the vocabulary people actually say, who is allowed to own what, and who is qualified to decide whether an agent's output is acceptable.

Writing one is a small job — a few hours if you know your domain. It should be done by someone who runs these sessions, not by someone reading about them.

Before you start

You do not need permission. Fork the repository, write your profile, open a pull request. If you would rather publish it yourself, do that instead — the licence permits it. We would still like to link to it.

Check whether one already exists. See profiles/. If there is a near-miss, extending it is usually better than starting over.

Write from real sessions. The two published profiles were written from transcripts of actual meetings. Vocabulary invented at a desk does not survive contact with a room; people revert to whatever they were saying before. If you cannot point at a session where someone used the word, do not put it in the profile.

What you are producing

Two files in profiles/, sharing a stem:

File	Purpose
`your-domain.json`	The machine-readable profile. Must validate against `schema/profile.schema.json`.
`your-domain.md`	The prose. Who it is for, the call types, ownership, adjudication, and at least one worked example.

Start from profiles/_template.json.

What you are NOT writing

Before the decisions, know what you can skip. The shared vocabulary — Ready, Hold, Clarify, Mine, Prompting, Add, Got it, Preliminary, Parked, Pass, and the rest — lives in the core specification, Section 7. Every profile inherits all of it automatically.

You do not restate those cues, and you cannot remove them or make a MUST-level one optional. Several carry invariants: if your profile quietly dropped preliminary, your domain would be exempt from a rule the Standard applies to everyone, which is not something a profile is permitted to do.

Your profile covers what is genuinely different about your trade. That is usually five things, plus an optional dialect.

The five decisions

1. Call types

The words people say to open the loop, in addition to the universal ones in core Section 7.2. Question is inherited; do not redeclare it. Aim for four to eight of your own.

A good call type is:

One or two syllables. It gets said dozens of times per session and it must survive a bad connection.
A kind of problem, not an artefact. "Bug" names a situation; "Ticket" names a thing you file.
Distinct from its neighbours. If two call types would route to the same owner and the same adjudicator, merge them.
Already in use. The best call types are the words your people say now.

Fewer than four usually means the vocabulary is too coarse to route ownership. More than eight and people stop remembering them.

2. Ownership eligibility

For each call type: who may own it?

The useful question is not who is most knowledgeable but whose work has to change as a result. In coordination settings that is almost always the right answer and it settles contention before it starts.

3. Adjudication

Who is qualified to decide whether agent output is acceptable?

This is the most important field in the profile, and the one most likely to be filled in vaguely. Be specific: name the role, the licence, or the position. "A senior person" is not a rule.

Two questions to settle:

Is there a legally designated responsible person? A professional in responsible charge, an attorney of record, an engagement partner, a credit officer, an attending physician. If a regulator or licensing body designates someone, that person is the Adjudicator and your profile cannot designate anyone else.
May the Owner adjudicate their own work? In unregulated settings, often yes. In regulated ones, usually not. Set owner_may_adjudicate accordingly.

4. Additional states

Most domains need none. Add one only where your domain requires a step the Core loop does not contain.

The two published profiles each add exactly one: software adds a verify step where the caller exercises the change, and AEC adds a sign_off step where acceptance is recorded in the project file separately from the verbal disposition.

You may add states and you may tighten requirements. You may not remove Core states, remove invariants, or lower a requirement from MUST to SHOULD. A profile that weakens the Standard is not a profile.

5. Retention

At Conformance Level 2 and above, what must be recorded and for how long?

If a regulation sets the period, cite it. If not, state your reasoning so a reader can judge whether it fits their jurisdiction. Do not present a retention period as legal advice.

The optional sixth: dialect

If your people already say something other than the core default for a cue, record it in cueDialect:

"cueDialect": {
  "acknowledge": {
    "phrase": "Listening",
    "note": "Standard in coordination rooms. Recorded from real sessions."
  }
}

A substitution keeps the cue's meaning and its requirement level. You are changing the word, not the rule.

Most profiles should have no dialect at all. The published AEC profile has two entries; the software profile has none. The test is simple: are you recording a word your people already say, or picking a word you think sounds better? Only the first is a dialect. The second is renaming for taste, and it makes the Standard harder to learn for no gain.

If you cannot point at a transcript where someone said your substitute word, use the core default.

Writing a profile