Answer-provenance profile: documented extension + reference bundle (product-customization seam)

[briananderson1222]

Answer-provenance profile: documented extension + reference bundle (the product-customization seam)

Driver: kontourai/station#1391. Station needs claim vocabulary for LLM-answer provenance: model/engine identity, routing receipt, tool-use records, cited sources with support strength. The owner directive: the base version must make sense, and product customizations must flow through an abstraction/extension point — not forks.

Surface's doctrine already answers the mechanism (docs/specs/producer-extension-limits.md): closed structure (strict validation, rejectUnknownKeys), open vocabulary (free-string facet/claimType/fieldOrBehavior/metadata), and the SurfaceExtension registry for claim-type definitions, console vocab/theme, and policy templates. Extensions must never touch derivation.

What's missing is the documented profile pattern itself — the first real consumer of the extension seam will set the convention every later product copies.

Scope

• Reference profile for answer provenance, registered via SurfaceExtension: claim-type definitions (llm-answer, routing-receipt, tool-use or similar), documented facet/metadata-key conventions, policy templates (e.g. requiring entailing citation evidence, distinct-actor corroboration)
• Reference bundle (new examples/answer-card/ or extending examples/system-card/) producing a bundle the answer-card projection renders end-to-end
• Docs: "Authoring a product profile" guide — how a product defines its vocabulary, what belongs in metadata vs claimTypes vs new Hachure fields (the Hachure-first path for anything structural; enum additions are version-sensitive), and the merge-interop warning: two products minting divergent claimType strings for the same concept can't reconcile in merged bundles — promote shared vocabulary to ops-level convention early
• Decide the packaging question: does the profile ship in the product repo (Station) with Surface documenting the pattern, or as a versioned @kontourai/surface-profile-* package? Recommendation: product repo first; promote only when a second consumer appears (extraction-after-proof)

Explicit non-goals (per doctrine)

• No facet registry/namespace machinery in core
• No derivation hooks for extensions
• No new typed schema fields for product-specific concepts (metadata is the channel)

[briananderson1222]

Implemented on branch glm/answer-profile (commit ce363ba): examples/answer-card (llm-answer claim, cited-vs-entails evidence, model-method derivation edge, ttl staleness through the real derivation ceiling — test-verified), registered SurfaceExtension profile, and docs/reference/authoring-a-product-profile.md codifying the seam + non-goals. Green: typecheck, tests, doc-links, package-contents.