[xgreenx]

The ceremony profile was written out four times — CeremonyProfile.sol and the two Platform Verifiers here, a hand table in libid-rs, and the browser's own copy in libid — with nothing relating them. The browser's copy has already drifted: it labels api.x.com the platform, when the platform is x and api.x.com is the authority. Nothing failed, because a Consumer dispatching on one string and a verifier registered under another simply never meet.

This does for the profiles what handles.json does for normalization: generated data, hand-written logic that reads it.

What changes

solidity/contracts/ceremony/profiles.json is the source of truth. scripts/regen-ceremony-profiles.py writes three files from it:

output	consumed by
solidity/contracts/ceremony/CeremonyProfile.sol	the Platform Verifiers, which now read it the way HandleNormalizer reads HandleVectors
rust/profiles/src/profiles.rs (new libid-profiles crate)	a Rust prover — the deployment's GitHub Token Service
ts/packages/contracts/src/ceremony/profiles.ts (@libid/contracts/ceremony)	the browser, which notarizes three of the four sessions

The Solidity constants are unchanged. Every platform id, authority, launch version, attestation count and protocol parameter generates byte for byte what was already there — the diff against the previous file is additions only, and 439 forge tests pass untouched. What's added is the session data the verifiers used to spell inline: request lines, the committed-body-field count, and the two identity field names. _tokenRequestLine() now returns CeremonyProfile.X_TOKEN_REQUEST_LINE.

Generation is not correctness

A wrong edit to profiles.json reaches all three languages at once, and they would agree perfectly on a platform no verifier is registered for. So the vectors stay and gain a second side: CeremonyProfile.t.sol pins the ids to cast keccak values, and the new crate's tests hash the generated strings and assert the same numbers.

The version guard

--check refuses a shipped profile whose values changed while its ceremonyVersion stayed put, reading the last release tag to know which is which. Exercised across five cases:

nothing changed	passes
prose reworded	passes — note is exempt
value changed, version held	fails: x/v1 changed since v0.7.0 but kept its ceremonyVersion
value changed, version bumped	passes
new platform added	passes — not a change to a shipped one

The check job now uses fetch-depth: 0: a shallow clone carries no tags, would find nothing to compare, and would pass in silence.

Release surface

libid-profiles has no runtime dependencies — the libid-identity shape, so a prover reads a table without inheriting anything to do it. It joins the single-version invariant (verify-tag.sh), bump-version.sh, the publish dry-run and the release publish. TypeScript gets a ./ceremony subpath export.

Verification

• python3 scripts/regen-ceremony-profiles.py --check and regen-identity-handles.py --check
• forge test — 439 passed; forge fmt --check
• cargo +nightly fmt --all --check, cargo clippy --workspace --all-targets -- -D warnings, cargo test -p libid-profiles — 6 vectors
• pnpm build, typecheck, test (24), lint, fmt:check

Follow-ups, not here

• libid-rs consumes libid-profiles and deletes its hand table (feat(transcript): the launch profiles, pinned to the numbers the chain holds libID-rs#10, closed pending this).
• libid replaces the browser's copy, which fixes the platform/authority confusion above.
• The IdShape enum is still hand-written in Solidity (IdShape.JsonString in the verifiers) while the JSON carries the shape. Generating a cast across the enum's ordinal was more coupling than it removed; worth revisiting.