Skip to main content
Human review is the safety layer between an expert’s reply and your system of record. When an expert answers, ShoulderTap structures the reply into a proposal and places it in the approval queue as pending. Nothing is delivered to a consumer until a person accepts it — the raw answer, the structured form, and the provenance are all shown so a reviewer can catch a wrong or poisoned answer before it’s written back.
The one exception is a consumer that registered with auto_accept: true, which delivers without review. It’s off by default precisely because skipping review is a real write-back-poisoning risk. See Consumers.

​
The web approval UI

shtap serve serves a single-page approval queue at the server root, http://localhost:8776/. It lists pending proposals and lets a reviewer accept or reject each one. The page prompts for the bearer token so it can call the API on your behalf.

​
From the CLI

1

List pending proposals

Prints each pending proposal with its id, the originating question, and the expert’s answer. If nothing is pending, it prints Nothing pending.
2

Accept a proposal

Marks the proposal accepted, records who decided it, delivers on_proposal_accepted to every subscribed consumer, and notifies the expert that their answer was accepted and attributed to them. --decided-by defaults to your OS username.
3

Reject a proposal

Marks the proposal rejected and delivers on_proposal_rejected (with the reason) to the consumer. --reason is required; --decided-by defaults to your OS username.

​
What acceptance does

Accepting a proposal:
  • Sets the proposal’s status to accepted and the request’s status to accepted.
  • Delivers the accepted proposal to all subscribed consumers (including any attached by deduplication) via on_proposal_accepted — this is where your consumer writes the answer to a system of record.
  • Sends the expert a notification that their answer was accepted, closing the loop on the attribution promise.
Deciding a proposal that’s already been accepted or rejected is a no-op.

​
Over the API

The same actions are available on the HTTP API:
  • GET /proposals?status=pending — the queue. See the Proposals endpoint.
  • POST /proposals/{id}/accept with { "decided_by": "alice" }.
  • POST /proposals/{id}/reject with { "decided_by": "alice", "reason": "not accurate" }.
You can trace every step a request took — received, asked, escalated, replied, decided — with GET /audit?request_id=.... See the Audit endpoint.