# SMSCode gated-verification — a zynk workflow-profile instance
A sanitized, publicly-derivable 4-role *gated-verification* multi-agent workflow,
expressed as a **zynk workflow-profile instance** (ADR 037). It declares its
roles, maps each role to the known integrity traits, and sequences its gates —
composing only existing zynk verbs. It is **one instance** among others, not
hardcoded anywhere in core.
This file is reference data. The deterministic enactment lives in
[`scripts/workflow-profile-smscode.sh`](../../scripts/workflow-profile-smscode.sh),
which issues the explicit `zynk assign` overlay commands below. The generic,
parameterizable form is in
[`gated-verification-template.md`](./gated-verification-template.md).
## Roles
| `operator` | Operator | `human` | *(none — human asserter + merge authority; a trait cannot be self-granted)* |
| `implementer` | Implementer | `agent` | `can_edit_source` |
| `collaborative-reviewer` | Collaborative Reviewer | `agent` | `can_verify_gate` |
| `independent-verifier` | Independent Verifier | `agent` | `independent`, `non_iterating`, `can_verify_gate` |
A **role** is fully free-form: the machine never reasons over the `role_id` (it is
dropped before the roster; only the escaped `role_label` renders). An integrity
**trait** is drawn only from the closed known vocabulary the machine *does* reason
over. Every trait here is **operator-asserted** with operator-grade provenance and
is **never self-granted** (the asserter, structurally `operator`, always differs
from the subject).
## Rationale
The **implementer** authors code, so it holds `can_edit_source` and is therefore
*not* independent — an author cannot be a decorrelated check on their own work.
The **collaborative reviewer** reviews while iterating *with* the implementer: it
is a gate (`can_verify_gate`) but it is deliberately **not** `independent` or
`non_iterating`, because iterating with the author correlates the review.
The **independent verifier** is the decorrelated, non-iterating gate
(`independent` + `non_iterating` + `can_verify_gate`). Its APPROVE is a
**required gate but not merge authorization**: passing the independent-verification
gate is necessary, but it does not by itself land the change.
The **human operator** is the merge/push authority and the final gate
(`actor_kind=human`, rendered distinctly — never as an agent). The operator holds
**no integrity trait**: a trait cannot be self-granted (the asserter is the
operator, so a trait *on* the operator would be a self-grant, rejected under
ADR 024), and the operator's merge authority is **structural**, not a granted
trait.
`can_merge_approve` stays in the closed trait vocabulary but is **not** assigned
in this reference. This profile makes the Operator the explicit merge authority and
the independent verifier the verification gate only; ADR 036 D11 sketches the
independent-verified badge around `independent` + `can_verify_gate`, not
`can_merge_approve` on the verifier's own gate. `can_merge_approve` remains
available for other profiles or a future, explicitly-justified authority model.
## Gate / phase sequence (descriptive)
```
implement → collaborative-review → independent-verify (gate) → operator-merge
```
This ordering is **descriptive only**. Track C Alpha does not machine-enforce
phase order; the sequence documents the team's intended flow and which role acts
at each gate. (A profile-declared, render-only phase rail is deferred — ADR 037
D7 γ.)
## Enactment
Run the deterministic reference script with the binary, DB, root, and session id:
```bash
ZYNK_BIN=zynk \
DB=.zynk/zynk.db \
ROOT=outputs \
SESSION_ID=s1 \
scripts/workflow-profile-smscode.sh
```
The script issues **only** `zynk assign actor-kind|role|trait` overlay commands —
nothing else. Every overlay is **operator-asserted** (`verified_by=operator`,
`command_origin=operator`, `transport=none`, `delivery_status=observed`) and is
**never `sent`**. Because the writes are overlay-only, they are **roster-only**:
they add zero feed/message rows and introduce no new sendable target. The
acceptance test `track_c_workflow_profile_smscode_roster_proof` in
`tests/zynk_cli.rs` runs this exact script and asserts those side effects.