No authoring input for custom labels / matchers (Recognition)

[martsokha]

Problem

The client-authored policy body (PolicyDraft) is { name, description?, rules?, scopes?, fallback? }. It no longer carries custom (inline custom-label definitions) or matchers (custom matchers) — those moved out of the policy body into a Recognition type: { custom?: Label[]; matchers?: CustomMatcher[] }.

The problem: in the generated SDK schema, Recognition appears only on Audit (the read-back analysis output). There is no authoring input that accepts a Recognition:

• PolicyDraft / CreateWorkspacePolicy / UpdateWorkspacePolicy — no recognition/custom/matchers.
• PipelineDefinition — references policies by policyIds only.
• CreateAdhocWorkspaceDetection — references policies by policyIds only.

So a client can read what custom labels/matchers a detection used (via Audit), but has no way to author them.

Impact (console)

The policy editor in nvisycom/studio has "Custom Labels" and "Custom Matchers" sections that still render and can be edited, but are silently dropped on save because there is no field to send them to. They are inert until an authoring path exists.

Asks

1. Expose an authoring endpoint/payload that accepts custom labels (a Recognition, or custom back on the policy/pipeline create-update body).
2. Confirm whether custom matchers are intentionally gone or should also be authorable. (Studio was told custom labels are still available, but custom matchers may be deliberately removed — please confirm.)

Once landed, studio can re-enable those editor sections; until then they stay inert-on-save.

[martsokha]

Confirmed — the claim holds against current main (elide-runtime 4f2d79d, elide b2580fa). There is no authoring input for custom labels or custom matchers anywhere in the server today; Recognition reaches the API only as read-back output on Audit.

What the code shows

Policy authoring DTOs carry no recognition — PolicyDraft (handler/request/workspace_policies.rs:49) is exactly { name, description?, scopes, rules, fallback? }; CreateWorkspacePolicy/UpdateWorkspacePolicy and their domain/input mirrors add nothing. PolicyDraftInput::into_definition builds the engine Policy with { id, name, description, template, scopes, rules, fallback } — no slot for custom/matchers.

It's not just off the DTO — it's off the policy entirely. The elide Policy type itself (elide-governance/src/policy/mod.rs) has no custom/matchers/recognition field. Upstream deliberately split recognition out of policies: policies bring scopes+rules (recompiled each call), while the custom labels/matchers a caller introduces for one run travel on RequestContext.recognition: Vec<Recognition>, parallel to policies — not inside them. So "put custom back on the policy body" isn't how upstream is shaped.

No per-run DTO carries it either — CreateAdhocWorkspaceDetection and PipelineDefinition reference policies by policyIds only; neither accepts recognition/custom/matchers. And the server's request_context builder (worker/detection/worker.rs) never calls .with_recognition(...) (grep across the server returns zero hits), so RequestContext.recognition is always empty. The doc comment there states it intentionally: recognition is currently treated as engine-owned.

Recognition in the schema is output-only — it appears solely via elide_pipeline::Audit (audit.rs:133, recognition: Vec<Recognition>), returned by the two GET audit endpoints (detection_audits.rs, workspace_redactions.rs). It's in no request/response DTO by name.

Answers to the two asks

1. Authoring path. None exists; it needs to be added. Because recognition is a per-run concept (recompiled fresh each call, not persisted policy state), the natural home is the detection/pipeline run request, not the policy body — matching upstream. Concretely: add an optional recognition (an elide_pipeline-re-exported Recognition, i.e. { custom: Label[], matchers: CustomMatcher[] }) to CreateAdhocWorkspaceDetection (and/or PipelineDefinition, with a domain/input twin), then thread it into RequestContext::with_recognition in worker/detection/worker.rs's request_context.

2. Custom matchers. Not intentionally gone. CustomMatcher ({ label, name, confidence, match_on: Pattern|Terms }) is fully alive upstream in elide-runtime 4f2d79d and accepted as run input via RequestContext.recognition. It's in the identical state to custom labels: present upstream, readable via Audit, un-authorable through the server. So studio's Custom Matchers section isn't chasing a removed capability — both sections are inert for the same reason (no server input field), and both are fixed by the same change.

Bottom line for studio

Keep both editor sections; they map to a real, live upstream capability. They stay inert-on-save until the server exposes a recognition input on the detection/pipeline run request and seeds RequestContext with it. That's a self-contained server change (request DTO + domain/input + one request_context line) — happy to pick it up once we agree it lands on the run request rather than the policy body.