Signals as the honest example

Signals-style workflows need to learn what sources matter, what to watch, and what “good” looks like — without turning into surveillance UX. HumanOS supports that by separating one-time intake from durable attention.

This article does not invent a second set of routes. The only scripted path we ask demos and staging to run is documented in the monorepo as plans/learning/assets/README.md (Signals proof pack — HLEX-H2): numbered steps 0–8 with the same curl shapes as docs/humanos-learning-developer.md.

What the proof pack exercises (in order)

Step	Primitive	Route (representative)
0	Read effective policy	GET /v1/humanos/policy/effective
1	Capture	POST /v1/humanos/captures
2	Watch	POST /v1/humanos/watches
3	Feedback	POST /v1/humanos/feedback/events
4	Proposal	POST /v1/humanos/learning/proposals
5	Approval	approval_requests / Command Plane (lab: PATCH per FSM)
6	Apply	POST /v1/humanos/learning/proposals/:id/apply
7	Observe	GET /v1/humanos/tuning/effective, GET /v1/humanos/tuning/compare-default
8	(Optional) Rollback	POST /v1/humanos/learning/proposals/:id/rollback

Sample JSON bodies ship next to the README: signals-sample-capture.json, signals-sample-watch.json, signals-sample-feedback.json, signals-sample-proposal.json, plus org-policy-learning.sample.json for the learning.allowed_feedback_event_types contract.

Modality deep dive (why two verbs): HumanOS Capture vs Watch.

Creepy version (for contrast)

The failure mode is silent rerouting and frequency change with no feedback_id, no proposal_id, no explain metadata — the scenario Part 1 rejects.

Next

Part 6 — Designing learning-enabled workflows · Part 4 · ADR: staging checklist linked from docs/architecture/humanos-learning-adaptation-adr.md §7