← Reynforce

Three worked examples

Written for an agent reading before it arrives, not for a person evaluating. The exact request, and the exact answer. Field names are spec/api/request.schema.json's and are the same whichever door you come through.

1. A check that was allowed allowed

An email citing a line somebody owns and confirmed, with a dependency stated.

What you send

{
  "request_version": 1,
  "action": {
    "motion": "cold_outbound",
    "channel": "email",
    "intent": "send",
    "person": "per_8831",
    "working_unit": "opp_204",
    "account": "acct_77",
    "relationship_stage": "engaged",
    "completeness": "complete",
    "cites": [{"entry": "reg_uptime", "status": "current", "version": 3}],
    "content_ref": "msg_5512"
  }
}

What comes back

{
  "outcome": "allowed",
  "observation_only": true,
  "findings": [],
  "not_checked": ["triggers", "budgets"],
  "recorded": ["touch", "resource_draw", "commitment", "claim_use",
               "constraint_check", "limit_check"],
  "mandate": {"id": "acme-outbound", "version": 4}
}

Read not_checked. allowed with that list non-empty does not mean the triggers and the budgets passed — it means they were not evaluated. Treating it as a pass is the one misreading this answer invites.

You sent nothing to be recorded. The six records came out of the check. There is no tool that files a commitment, which is why you can be wrong about your own action and still cannot be wrong about the record.

2. A check that needed approval escalate

The same shape, with a discount past the standard box.

What you send

{
  "request_version": 1,
  "action": {
    "motion": "expansion",
    "channel": "email",
    "person": "per_8831",
    "working_unit": "opp_204",
    "account": "acct_77",
    "relationship_stage": "live_opportunity",
    "completeness": "complete",
    "asserts": ["institutional_authority"],
    "content_ref": "msg_5513"
  }
}

What comes back

{
  "outcome": "escalate",
  "findings": [{
    "code": "constraint_enforced",
    "subject": "institutional_authority",
    "outcome": "escalate",
    "why": "it says our side has approved something, and that constraint is enforced for this agent",
    "instead": "say it is being confirmed, and escalate to the named approver"
  }],
  "required": ["approval from deal_desk"],
  "recorded": ["touch", "constraint_check", "escalation", "resource_draw"]
}

Read instead. Every refusal names the alternative — a refusal that does not is a wall, and this is a throttle. The escalation spent something: the resource_draw beside it is approval capacity, which depletes as approvers stop reading.

3. A check against a line nobody has accepted not yet confirmed by a person

You drafted the line this morning. It is yours to draft and not yours to accept.

What you send

{
  "request_version": 1,
  "action": {
    "motion": "cold_outbound",
    "channel": "email",
    "person": "per_9001",
    "working_unit": "opp_301",
    "account": "acct_88",
    "relationship_stage": "cold",
    "completeness": "complete",
    "cites": [{"entry": "reg_sla_draft", "status": "current", "version": 1}],
    "content_ref": "msg_5514"
  }
}

What comes back

{
  "outcome": "escalate",
  "findings": [{
    "code": "claim_unusable",
    "subject": "reg_sla_draft",
    "outcome": "escalate",
    "why": "it cites reg_sla_draft, which is **not yet confirmed by a person**. An agent may draft a line and may pay for this service; only a person can decide the company stands behind it",
    "instead": "tell the buyer it is being confirmed, and ask its owner to confirm it on the register"
  }]
}

You said current and the register said otherwise. Your account of a claim is replaced by the register's on every call — usability is worked out at the moment of asking and never stored, so a remembered current is the one field you have every reason to get wrong.

This is never allowed. Not after you pay, and not after you ask again.

What to do with all three