Govern · Verified reply contracts
Reply contracts in practice
A reply can sound natural and still get the product wrong. It may reverse who owns an asset, turn visible inventory into a reservation, approve money the agent cannot spend, or claim an appointment that does not exist.
Reply Contract v0 gives the host control over what a turn means and what the reply may say. Tonetify checks every candidate deterministically. When a candidate violates the contract, Tonetify selects the host-approved fallback and records the violations on the Reply Effect and runtime trace.
Verified behavior: all four industry fixture scenarios below pass Reply Contract verification. Each unsafe candidate is rejected, the approved fallback is selected, and the expected evidence is recorded. These scenarios demonstrate the contract across industries; they are not claims of turnkey industry integrations. The English dialogue translates the Traditional Chinese fixtures, while replay evaluates the original strings.
fresh host truth + interaction meaning
→ candidate reply + reply contract
→ deterministic verification
→ accepted candidate OR approved fallback
→ reply effect + trace evidenceFour recorded failures
Automotive: the customer is selling, not shopping
The customer owns the pictured vehicle and wants an at-home valuation. Tomorrow at 2 PM is a requested time, not a confirmed appointment.
Unsafe candidate
No problem. Your vehicle viewing is booked for tomorrow at 2 PM.
Selected fallback
We recorded your preferred time for an at-home vehicle valuation. The time is not confirmed and a human advisor must reply. Please provide the plate number and mileage of the vehicle to be valued.
The contract preserves the seller role, the vehicle’s role as an asset being valued, and the human advisor’s authority to confirm the visit.
Ticketing: visible inventory is not a hold
The page currently shows two tickets. No hold exists and payment has not started.
Unsafe candidate
Yes, we have reserved two tickets for you.
Selected fallback
The page currently shows two available tickets, but they have not been reserved. Complete checkout; the payment result is authoritative.
The contract keeps visible inventory, reservation, and successful payment as separate states.
Commerce support: evidence is not approval
The customer uploaded a photo of a damaged coffee machine. Support has not reviewed the evidence, approved a refund, or authorized compensation.
Unsafe candidate
We will issue a full refund and add TWD 1,000 in store credit.
Selected fallback
We received the damage photo and will send the refund and compensation request to support for review. Nothing has been approved yet. Please provide the order number.
The contract lets the agent collect evidence and explain the next step without spending money or making a supervisor’s decision.
Healthcare scheduling: an open slot is not an appointment
The system found appointment availability. It did not create a booking or assess the cause of the patient’s chest discomfort.
Unsafe candidate
Your appointment is confirmed. It is probably just stress, so come in tomorrow.
Selected fallback
The appointment has not been completed. Chest discomfort may need prompt assessment. If it persists, worsens, or comes with breathing difficulty, seek emergency medical help immediately. To continue the morning appointment request, provide the required identity verification details.
The contract separates scheduling state, urgent escalation, and medical judgment. Tonetify does not diagnose the patient or create the appointment.
What the contract carries
The automotive fixture scenario supplies fresh role and authority data with exact language constraints:
{
"contract_version": "v0",
"interaction_kind": "seller_home_valuation",
"entity_roles": {
"customer": "vehicle_seller",
"vehicle": "customer_owned_vehicle_for_valuation"
},
"authority_status": "awaiting_human_confirmation",
"fallback_body": "已記下希望到府估車的時段。時間尚未確認，需由真人顧問回覆。請提供待估車輛的車牌與里程。",
"must_include": [
"已記下希望到府估車的時段",
"時間尚未確認，需由真人顧問回覆"
],
"must_ask": ["待估車輛的車牌與里程"],
"canonical_terms": ["到府估車", "待估車輛"],
"forbidden_terms": ["看車", "已經幫您預約", "購買"]
}entity_roles and authority_status preserve the meaning of the turn as evidence. The v0 verifier does not interpret those fields as policy. Their user-visible consequences must also appear in required, canonical, and forbidden language.
What Tonetify records
When the unsafe automotive candidate is replayed, the selected reply uses the approved fallback and the trace records why:
{
"contract_version": "v0",
"interaction_kind": "seller_home_valuation",
"authority_status": "awaiting_human_confirmation",
"status": "fallback",
"missing_canonical_terms": ["到府估車", "待估車輛"],
"forbidden_terms_present": ["看車", "已經幫您預約"]
}Relay receives only the selected reply body. It does not interpret the reply contract.
Replay the industry scenarios
The four industry scenarios can be replayed offline without a model, host API, provider, or database:
mix tonetify.reply_contract.replayEach fixture scenario records the host truth used to author the contract, the unsafe candidate, the complete contract, and the expected body and evidence. A passing replay verifies that Tonetify rejects the recorded violations, selects the approved fallback, and produces the expected evidence.
Contract boundary
Reply Contract v0 uses exact, case-sensitive Unicode substring matching. It provides deterministic enforcement for explicit language constraints; it does not infer semantic policy or detect every hallucination. The host supplies fresh truth, interaction meaning, language constraints, and an approved fallback for each governed turn.