v0.6 Draft
Informative

Writing a profile

A few hours of work if you already run these sessions. You do not need permission — fork it, write it, open a pull request.

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:

FilePurpose
your-domain.jsonThe machine-readable profile. Must validate against schema/profile.schema.json.
your-domain.mdThe prose. Who it is for, the call types, ownership, any approval requirement, 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, Heard, Mine, Prompting now, Adder, Go ahead, Preliminary, Status, 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 resolve the same way, 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. Approval

Does your profession require a second signature before anyone relies on this?

In the core, the Owner closes their own task. That is the default and most profiles should leave it alone — delete the approval block entirely.

Declare one only where a profession or jurisdiction requires a named person to accept the result before anyone relies on it: a professional in responsible charge, an attorney of record, an engagement partner, a credit officer, an attending physician. If a licensing body designates who holds that responsibility, name that person and no one else — you are recording their rule, not writing your own.

Be specific. Name the role, the licence, or the position, in your domain's own language. "A senior person" is not a rule.

Two traps:

  • Do not add approval because it feels more rigorous. Every approval step converts a question answered inside the meeting into a follow-up item, which is the exact failure this Standard exists to prevent. Add it because your regulator requires it, not because it reads as careful.
  • Approval is not ownership. The Owner still closes the task and still states the disposition. Approval is an additional gate on reliance, not a transfer of accountability.

If what you actually want is "somebody must check this before we call it done", that is usually an additional state (decision 4), not an approval requirement. The software profile is the worked example: it requires the Caller to exercise a change before it can be closed Accepted, and declares no approver at all.

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. Today none do. The AEC profile declared two entries until version 0.5, when both were checked against the recording they claimed to come from and neither phrase appeared in it. They were deleted.

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. Expect to be asked where you recorded it.

acknowledge is locked and cannot be substituted at all — see Core §7.3. It is the one utterance the whole room produces in answer to the same trigger, so it has to survive an outsider joining the meeting.

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

The worked example

Your prose file MUST contain at least one worked example: a short dialogue showing the loop running end to end in your domain, with your vocabulary.

This is the part practitioners actually read. Make it real. A worked example that ends Parked with a named blocker teaches more than one that ends Accepted, because the ambiguous endings are where sessions break down.

Checklist before opening a pull request

  • your-domain.json validates against schema/profile.schema.json (npm run validate)
  • id matches the filename stem and is lowercase and hyphenated
  • No call type duplicates a universal one (Question)
  • Every cueDialect entry names a real, unlocked cue id and records a phrase your people actually say
  • No cueDialect entry names a locked cue such as acknowledge
  • No dialect entry restates the core default unchanged
  • Every call type has a meaning a newcomer could act on
  • The approval block is absent unless a profession or jurisdiction genuinely requires it
  • Where present, approver names a specific role, licence, or position and notes cites the basis
  • No Core state has been removed and no requirement lowered
  • The prose file contains a worked example with real vocabulary
  • Retention cites a regulation or states its reasoning
  • status is draft unless a practitioner in the domain has reviewed it

Review

Profiles are reviewed for structural conformance — that the schema validates and that no invariant has been weakened. They are not reviewed for domain correctness, because the maintainers are not qualified in every domain.

A profile marked published means a practitioner in that domain has reviewed it. If you are that practitioner, say so in maintainers and we will mark it published. If nobody has, it stays draft, which is an honest label rather than a demotion.