Main pane states:
Mockup for SPEC.md §8 — not real app code
OHM RFC Contributor wiggleverse/ RFC-0042 · Open Human Model /
B
RFC-0038Capability negotiation
RFC-0040Provider keys & rotation
RFC-0042Open Human Model
Main
● main v1 · 4d ago
Open PRs (1)
⇪ #4 split §5 into §5/§5a alice
Open branches (3)
⎇ ben/clarify-graduation 2d
⎇ raj/inline-arbiters 5d
⎇ jo/spike-id-scheme 9d
Closed (3) show ▾
super-draftConflict resolution model
RFC-0035Bot service account
main v1 · merged 4d ago by ben In flight: PR #4 · split §5 · 1d ben/clarify-graduation · 2d raj/inline-arbiters · 5d jo/spike-id-scheme · 9d
RFC-0042 · Open Human Model
Active · owners ben, raj · arbiters ben · tags identity, schema

# Open Human Model

This is the canonical, merged-to-main version. Drill into a branch or PR (left pane or chips above) to see proposed changes.

## 1. Why this RFC exists

The Open Human Model (OHM) is the schema that lets a contributor describe themselves to the rest of the system in a way that other tools — RFCs, applications, the meta-repo's directory — can read uniformly.

## 2. Scope

This RFC defines the on-disk shape of an OHM record, its required and optional fields, the versioning policy, and the migration path from the prior ad-hoc `profile.yaml`.

## 3. Schema

An OHM record is a YAML document with a frontmatter block of canonical fields and an open free-form body. The canonical fields are…

## 4. Versioning

OHM follows semantic versioning at the document level. Major bumps may break consumers; minor bumps add fields…

⎇ ben/clarify-graduation ◂ compared to main
5 changes across 3 sections +34 lines −18 lines · 2 accepted, 2 pending, 1 declined

## 1. Why this RFC exists

§1 ¶1The Open Human Model (OHM) is the schema that lets a contributor describe themselves to the rest of the system in a way that other tools — RFCs, applications, the meta-repo's directory — can read uniformly.

§1 ¶2Today, every consumer reaches into the ad-hoc `profile.yaml` and projects its own subset of fields. The result is silent drift: two consumers can read the same file and disagree about what a contributor's handle even is.

▴ §1 unchanged · 2 paragraphs · expand

## 2. Scope

§2 ¶1This RFC defines the on-disk shape of an OHM record, its required and optional fields, the versioning policy, and the migration path from the prior ad-hoc `profile.yaml`.

§2 ¶2It does not define an API for reading OHM records, nor a publishing protocol — those are independent concerns and will be specified in their own RFCs.

▴ §2 unchanged · 2 paragraphs · expand

## 3. Schema

§3 ¶1An OHM record is a YAML document with a frontmatter block of canonical fields and an open free-form body. The frontmatter is what consumers parse; the body is for the contributor to write in.

§3 ¶2 Claude · sonnet-4.5 from anchored thread "schema field naming" Accepted
−The canonical fields are `name`, `handle`, `pronouns`, and `bio`.
+The canonical fields are `display_name`, `handle`, `pronouns`, `bio`, and `established_at`.
+The `display_name` rename clarifies that this field is the human-facing label, distinct from the immutable `handle`.
Accepted by ben · 4h ago · edited before accepting
C schema field naming
"the name field is ambiguous — display label or stable id?" → Claude proposed renaming…
§3 ¶3 (new paragraph) Manual · ben Accepted
+A record's `established_at` is the date the contributor first claimed this OHM, expressed as ISO-8601. Subsequent edits do not bump it.
Typed directly by ben · 4h ago

§3 ¶4Each field has a normative type in §3.1 (string, ISO-8601 date, list of strings, etc.) and a non-normative example in §3.2. Consumers MUST validate the type and SHOULD treat any extra field they don't recognize as opaque.

§3 ¶5The free-form body is plain Markdown. It is intended for the contributor's own narrative — bio, working hours, time-zone notes, whatever they want collaborators to know. Consumers that don't render Markdown should pass the body through unchanged.

▴ §3 ¶4–5 unchanged · 2 paragraphs · expand

## 4. Versioning

§4 ¶1 Claude · sonnet-4.5 from anchored thread "is semver overkill?" Pending
OHM follows semantic versioning at the document level.
−Major bumps may break consumers; minor bumps add fields without breaking; patch bumps are clarifications.
+Major bumps may break consumers (renamed or removed fields); minor bumps add optional fields; patch bumps are clarifications that don't change the schema's shape.
+Consumers MUST tolerate unknown optional fields; producers MUST NOT emit major versions without a written migration note in the RFC's repo.
Proposed by Claude · 3h ago
C is semver overkill?
"do we really need MAJOR/MINOR/PATCH for a schema this small?" — discussion led to a more explicit producer/consumer contract…

§4 ¶2The current version is `v1`. The version is encoded as a single integer prefix (`v1`, `v2`, …) at the top of the file rather than embedded in the schema URI, so that consumers can read it without parsing.

▴ §4 ¶2 unchanged · expand
§4 ¶3 Claude · gemini-2.5 from anchored thread "migration ergonomics" Pending
+Migration scripts live alongside the RFC in `.ohm/migrations/<from>-><to>.py`. The bot runs them on graduation.
Proposed by Claude · 1h ago
C migration ergonomics
Selection asked: "how does a downstream tool know there's a migration to run?" — Claude proposed convention…

§4 ¶4A version bump is a commit to this RFC's repo. The commit message MUST start with `v<n>:` and the body MUST summarize the changes in human-readable terms. Tooling depends on this format.

▴ §4 ¶4 unchanged · expand

## 5. Migration from `profile.yaml`

§5 ¶1 Claude · sonnet-4.5 Declined
−The migration tool reads the legacy `profile.yaml` and emits a v1 OHM record, preserving unknown fields under a `legacy:` key.
+The migration tool DELETES the legacy profile.yaml after emitting the v1 OHM record. Legacy fields are dropped.
Declined by ben · 2h ago · "we want non-destructive migration"

§5 ¶2The tool runs once per contributor, idempotently. Re-running it on an account that's already migrated is a no-op: the tool reads the existing v1 record, validates it, and exits.

§5 ¶3Failure modes are noisy by design. A malformed legacy file aborts the migration with a clear error pointing at the offending line; nothing is half-migrated.

§5 ¶4For accounts that never had a `profile.yaml`, the tool seeds a minimal v1 record with only the `handle` field populated from the Gitea login.

▴ §5 ¶2–4 unchanged · 3 paragraphs · expand
⎇ ben/clarify-graduation ◂ compared to main
Editing on ben/clarify-graduation · Inline track-changes shown · click a pin to open its conversation 2 accepted 2 pending in the diff view

## 3. Schema

An OHM record is a YAML document with a frontmatter block of canonical fields and an open free-form body. The canonical fields are namedisplay_name1, `handle`, `pronouns`, and `bio`, and `established_at`. The `display_name` rename clarifies that this field is the human-facing label, distinct from the immutable `handle`.

A record's `established_at` is the date the contributor first claimed this OHM, expressed as ISO-8601. Subsequent edits do not bump it.

## 4. Versioning

OHM follows semantic versioning at the document level. Major bumps may break consumers; minor bumps add fields without breaking; patch bumps are clarifications. 2 — 1 pending proposal in this paragraph

Migration scripts live alongside the RFC. 3 — 1 pending proposal

## 5. Migration from profile.yaml

The migration tool reads the legacy `profile.yaml` and emits a v1 OHM record, preserving unknown fields under a `legacy:` key.

⇪ PR #4 "Split §5 into §5 / §5a" ◂ alice → main
PR #4 by alice · opened 1d ago · 2 reviewers · all conversations resolved · discussion thread
8 changes +47 lines −12 lines · All 8 accepted on the branch

## 1. Why this RFC exists

§1 ¶1The Open Human Model (OHM) is the schema that lets a contributor describe themselves to the rest of the system in a way that other tools can read uniformly.

## 2. Scope

§2 ¶1This RFC defines the on-disk shape of an OHM record, its required and optional fields, the versioning policy, and the migration path from the prior ad-hoc `profile.yaml`.

## 3. Schema

§3 ¶1An OHM record is a YAML document with a frontmatter block of canonical fields and an open free-form body. The canonical fields are `display_name`, `handle`, `pronouns`, `bio`, and `established_at`.

## 4. Versioning

§4 ¶1OHM follows semantic versioning at the document level. Major bumps may break consumers; minor bumps add optional fields; patch bumps are clarifications.

▴ §1–4 unchanged on this PR · expand
§5 → §5 + §5a (split) Claude · opus-4 from anchored thread "section is too long" Accepted on branch
−## 5. Migration from profile.yaml
−The migration tool reads the legacy profile.yaml and emits a v1 OHM record…
+## 5. Migration: legacy → v1
+Migrating an existing `profile.yaml` happens once per contributor, on first sign-in after this RFC ships.
+
+## 5a. Migration tool reference
+The tool reads the legacy file, emits a v1 OHM record, and preserves unknown fields under a `legacy:` key.
Conversation resolved · approved by raj

§5a ¶2The tool runs once per contributor, idempotently. Re-running it on an account that's already migrated is a no-op.

§5a ¶3Failure modes are noisy by design. A malformed legacy file aborts the migration with a clear error pointing at the offending line; nothing is half-migrated.

## 6. Open questions

§6 ¶1Should the migration tool be runnable offline, or only at first sign-in? Leaving as future work.

▴ §5a ¶2–3 + §6 unchanged · expand
💬 Branch chat 2 msgs · whole-doc context
§3 ¶2 · 24 chars selected
"The canonical fields are name, handle, pronouns…"
"the name field is ambiguous — display label or stable id?" — Claude proposed renaming + adding established_at field.
4 msgs 1 accepted · 4h ago
§4 ¶1 · 86 chars selected
"Major bumps may break consumers; minor bumps…"
"do we really need MAJOR/MINOR/PATCH for a schema this small?" — discussion led to a more explicit producer/consumer contract.
9 msgs 1 pending · 3h ago
§4 ¶3 · 0 chars (paragraph)
"how does a downstream tool know there's a migration to run?" — Claude proposed naming convention for migration scripts.
3 msgs 1 pending · 1h ago
§5 ¶1 · 42 chars selected
"should we ever delete the legacy file?" — Claude proposed destructive migration; declined by ben.
5 msgs 1 declined · 2h ago
§3 ¶2 — anchored to selection
"The canonical fields are name, handle, pronouns…"
ben
the name field here is ambiguous — is it the display label or the stable identifier? I keep tripping over it when writing downstream code.
Claude sonnet-4.5
Good catch — it's currently overloaded. Two clean options: (1) rename `name` → `display_name` and keep `handle` as the immutable id, or (2) add a separate `display_name` alongside `name` and deprecate `name`. Option 1 is cleaner since `name` is already unstable in practice.
ben
go with (1). also — we never wrote down "when did this OHM start existing." add an `established_at`.
Claude sonnet-4.5
Done. Proposed two coupled edits to §3 ¶2 — the rename plus the new field, with a one-line note explaining the rename.
✓ 1 change accepted · §3 ¶2
sonnet-4.5