Skip to content

Canon extensibility spike — third-party entity types over the shared core (post-launch) #665

Description

@wow-miley

Context

Deferred in #654's out-of-scope ("this split is its prerequisite, not its delivery"); filed early by request. Once bindings live in edge modules and ampere-core is pure vocabulary, the extension question opens: can a third-party consumer add app-specific entity types through the same entity protocol (canonId + canonType-like discrimination + provenance + serialization discipline) without reopening the closed core canon?

The tension to resolve: the canon's value is that it is shared — but a sealed hierarchy means third parties cannot add members at all today, and the recorded design stance is "extension upward, not evacuation downward." An Arc marketplace eventually needs an answer.

Gate: post-launch. Opens after #654 merges (the split is the structural prerequisite) and only when a concrete consumer demand exists — this spike should not run on speculation alone.

Objective

A recorded verdict on the extension mechanism: sealed-core + open extension interface, versioned canon expansions only (no third-party types ever), or a namespaced extension registry — with the trace/replay, consent-ledger, and cross-consumer-interop implications named per option.

Expected Outcomes

  • Analysis of each mechanism against the properties that make the canon valuable: exhaustive when for core types, PlaybackRelay replay of traces containing unknown extension types, consent grants over extension types, and whether two apps sharing an extension can interoperate
  • A recommendation with the marketplace implications stated (extension types in published Arcs: allowed, versioned, or forbidden)
  • Verdict recorded; implementation tickets drafted only after

Tasks

  1. Survey precedent (schema.org extension mechanics, protobuf unknown-field handling, kotlinx polymorphic open serialization) for the replay-of-unknown-types problem specifically
  2. Analyze the three mechanisms against the four properties above
  3. STOP — verdict recorded before anything is drafted

Technical Constraints

Core canon stays closed and sealed regardless of outcome; nothing here may weaken the serialization tripwire or the no-Custom(payload) stance — an extension mechanism that amounts to an escape hatch fails by definition.

Out of Scope

Implementation; marketplace payout/review mechanics; any change to existing canon types.

Agent: Opus (analysis spike, no code)

Metadata

Metadata

Assignees

Type

No type

Projects

Status
Backlog

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions