Context
elide is gaining a reviewable operator-selection phase (nvisycom/elide#165): after detection, analyze produces a Report; a new select() step stamps a pending, editable operator pick (Selection) per entity onto that Report before anything is applied. A reviewer can inspect and override each pick, then apply() runs the (possibly-edited) selections.
To keep elide a self-contained, serde-first framework, the serialized Selection carries policy only — an operator id + its serde config — never live operators and never secrets. Turning that id + config back into a live Box<dyn Operator>, and supplying secret capabilities (keys, vault), is the runtime's job. This issue tracks that runtime-side work.
Scope (runtime owns)
- Operator registry —
id + config → Box<dyn Operator>, knowing every elide built-in operator's constructor. Extensible for any custom operators the runtime ships.
- Capabilities wiring — supply runtime-only secrets to reconstruction:
KeyProvider (HMAC/AES keys), pseudonymize vault, etc. These live on the runtime side (a TypeMap or equivalent), never on the wire. elide already keeps secrets out of serialized policy (see KeyProvider in elide-redaction: "wired at operator construction … never from serialized policy").
- HTTP round-trip — serialize the
Report (with its Selection map) to JSON, send to the product, deserialize edits back. The Report is already serde.
- Override plumbing / UI — surface elide's initial pick per entity, let a reviewer override the operator (and/or config), mark it as an override so clustering honors it verbatim.
- Resolver seam — implement whatever elide's
apply() expects to turn a Selection into a live operator (closure or OperatorResolver trait — final shape TBD in elide#165), backed by the registry + capabilities above.
Boundary
- elide defines: operators + their serde configs, the
Selection type, select()/apply(), and the resolver seam. elide never reconstructs operators from config and never links runtime code.
- runtime (this issue) owns: the id→constructor registry, secret capabilities, HTTP transport, and the review/override UI.
Depends on
Blocked until elide's select/apply + resolver seam land with a concrete signature to implement against.
Context
elide is gaining a reviewable operator-selection phase (nvisycom/elide#165): after detection,
analyzeproduces aReport; a newselect()step stamps a pending, editable operator pick (Selection) per entity onto that Report before anything is applied. A reviewer can inspect and override each pick, thenapply()runs the (possibly-edited) selections.To keep elide a self-contained, serde-first framework, the serialized
Selectioncarries policy only — an operator id + its serde config — never live operators and never secrets. Turning thatid + configback into a liveBox<dyn Operator>, and supplying secret capabilities (keys, vault), is the runtime's job. This issue tracks that runtime-side work.Scope (runtime owns)
id + config → Box<dyn Operator>, knowing every elide built-in operator's constructor. Extensible for any custom operators the runtime ships.KeyProvider(HMAC/AES keys), pseudonymize vault, etc. These live on the runtime side (a TypeMap or equivalent), never on the wire. elide already keeps secrets out of serialized policy (seeKeyProviderin elide-redaction: "wired at operator construction … never from serialized policy").Report(with itsSelectionmap) to JSON, send to the product, deserialize edits back. The Report is already serde.apply()expects to turn aSelectioninto a live operator (closure orOperatorResolvertrait — final shape TBD in elide#165), backed by the registry + capabilities above.Boundary
Selectiontype,select()/apply(), and the resolver seam. elide never reconstructs operators from config and never links runtime code.Depends on
Blocked until elide's
select/apply+ resolver seam land with a concrete signature to implement against.