Specialist feedback — draft

Status: Draft for joint review; not ratified or a published extension. There is no published feedback discovery extension. The path below is the Roblox pilot API, not a requirement imposed on other agents.

Route to the evidence owner

The Workbench needs to retain the originating specialist registration and task ID when forwarding a result. Feedback goes to that specialist under the same authenticated machine/human owner that produced the run. A parent coordinator task ID cannot replace the specialist task ID. If an answer combines multiple specialists, the UI needs an explicit feedback target; it must not silently send one rating to all contributors.

Resolve the specialist endpoint through approved registration/discovery, not an arbitrary URL in model output. Never send credentials to an artifact-supplied destination. Identity and client binding remain a separate prerequisite.

Roblox pilot behavior, reported 2026-10-21

The Roblox owner confirmed this implementation:

{
  "id": "e429c8d8-8e9e-4e96-aab8-cae4b07e9c1e",
  "taskId": "specialist-task-id",
  "rating": "up",
  "comment": "The cited study answered the question."
}

• POST /api/feedback accepts a UUID id, taskId, rating of up or down, and optional comment of at most 4000 characters. Success is HTTP 201 with { "id": "<submitted UUID>", "saved": true }.
• The task/run belongs to the same authenticated machine/human owner and is no longer running. Caller identity comes from auth, not the body.
• Exact owner/UUID/body retries are idempotent. Reusing the UUID with a changed payload returns 409; it is not an update operation. New UUIDs can create multiple ratings for the same task.
• GET /api/feedback returns the newest 100 own feedback rows without pagination. The operator all-caller list is /api/analytics?scope=all.
• Operator PATCH /api/feedback accepts {id, owner, resolution} and overwrites the resolution. owner is the opaque returned owner key, not a human subject. This is not a normal user rating operation.

The pilot UI caps comments at 2000 characters and loses its feedback UUID and saved state on reload. A Workbench implementation should persist the submitted UUID and payload for retries; it should not treat reload or a network timeout as permission to create another rating.

Workbench pilot implementation, 2026-10-21

Local Workbench code provides an explicit roblox-v1 registry opt-in, not a new discovery extension. The relay authorizes against persisted specialist task provenance and the authenticated conversation owner. It uses the registered HTTPS origin, not an artifact-supplied URL.

Workbench persists one immutable submission per human, agent, task and configured client. It sends the same UUID/payload on an explicit retry and marks it saved only after the matching HTTP 201 acknowledgement. The UI loads pending/saved state and caps comments at 4000 characters. This is narrower than Roblox's API, which permits multiple UUIDs per task.

Disposable Postgres tests cover ownership, pending failures, conflicting payloads, exact retries and acknowledgement validation. This does not certify the deployed authentication path or specialist evidence join.

Decisions and acceptance still required

Agree a versioned discovery declaration, supported operations, portable request/response schema, retention/privacy policy, and whether rating edits are supported. Until then, do not invent a feedback URL for arbitrary registered agents or advertise automatic feedback routing as complete.

Test exact retries, conflicting retries, unauthorized/cross-owner task IDs, in-progress tasks, multi-specialist provenance and UI reload. Verify that the saved feedback joins the intended specialist's run/tool evidence, not merely that the HTTP request succeeded.