# Decision PS-DEC-01: evaluate a review queue

**Synthetic demonstration decision; no human approval or production release is
claimed.** Business: Northstar Office Supply. Rule: PS-RULE-01, version 1.

The fictional evidence suggests two options:

| Option | Benefit | Remaining responsibility |
| --- | --- | --- |
| Add an owner checklist to invoice intake | Clarifies the procedure without automation | A person checks every invoice and assigns the queue |
| Evaluate the owner and amount rule in a workflow | Makes the queue rule executable and testable | A person still supplies complete data and reviews the invoice |

This demonstration selects the second option only to test native workflow
generation and execution. It does not establish an automation recommendation for
a real business, commercial value, or a customer's authorization.

The output is a queue label, never an approval or payment. The intended sequence
is a scheduled trigger, synthetic fixture input, then rule evaluation. Five
parallel fixture paths exercise the same rule, including the threshold and
missing-owner exceptions. No HTTP requests, credentials, messages, accounting
updates, or money movement are included.

The primary IR expresses PS-RULE-01 as a `data.transform` expression. The separate
`branch-diagnostic` artifact probes the compiler's `condition.branch` mapping for
the amount threshold only; it is not the full owner rule. Both preserve actual
compiler output without native JSON repairs.

## Acceptance criteria and release boundary

All five native outputs must contain the expected invoice ID and review queue.
An n8n process exit code or engine status of `success` alone does not satisfy this
criterion. See the actual result in `validation.json` and `run-result.json`.

The CLI harness adds a Manual Trigger and copies the generated schedule trigger's
outgoing connections. It preserves every generated node and existing connection.
This allows isolated execution of the fixture/rule paths; scheduled delivery is
not tested. The generated native artifact and the test harness are separate files.

Product fidelity findings and approval requirements are retained. No approval
record, product runtime deployment, live account, production activation, or
scheduled delivery is represented by this test.