Govern · Emerging evidence contract
Record host execution evidence
After an authorized host mutation, the host can attach durable evidence to an existing ExecutionPermit. Tonetify records that evidence. It does not perform the mutation, decide the business outcome, or replace the host’s own records.
existing ExecutionPermit
→ host execution
→ ExecutionReceipt
→ optional WitnessEvent
→ optional ReversalEvent| Contract | Current status |
|---|---|
| Version | host-evidence-v0 |
| Authentication | Host bearer token |
| Authority | Host executes; Tonetify records evidence |
| Maturity | Emerging host-facing API |
Authentication and scope
Send Authorization: Bearer <host-api-key>. The token must resolve to a bot profile in the same organization as the permit in the URL.
Receipt writes must also present an existing permit_credential_id that belongs to that permit. This checks organization and permit correlation. It is not credential signing or proof that a bearer token is cryptographically bound to the credential.
Record an execution receipt
POST /api/execution-permits/<execution-permit-id>/receipts
Authorization: Bearer <host-api-key>
Content-Type: application/json{
"idempotency_key": "receipt-api-1",
"permit_credential_id": "permit-credential-id",
"receipt_ref": "host-receipt-1",
"status": "succeeded",
"executed_at": "2026-05-28T00:00:01Z",
"outcome": {},
"evidence": {}
}Tonetify derives organization, permit, host, action, resource, subject, and executor scope from the persisted permit. Host-supplied fields cannot expand that scope.
Record witness evidence
POST /api/execution-permits/<execution-permit-id>/witness-events
Authorization: Bearer <host-api-key>
Content-Type: application/json{
"execution_receipt_id": "receipt-id",
"idempotency_key": "witness-api-1",
"witness_kind": "host",
"event_kind": "receipt_attested",
"observer_ref": "hr_knowledge_host",
"subject_ref": "host-receipt-1",
"evidence_ref": "knowledge:annual_leave",
"observed_at": "2026-05-28T00:00:02Z",
"evidence": {},
"metadata": {}
}execution_receipt_id is optional. When supplied, the receipt must belong to the same permit.
Record reversal or remediation evidence
POST /api/execution-permits/<execution-permit-id>/reversal-events
Authorization: Bearer <host-api-key>
Content-Type: application/json{
"execution_receipt_id": "receipt-id",
"idempotency_key": "reversal-api-1",
"reversal_kind": "remediation",
"status": "requested",
"actor_ref": "operator-1",
"target_ref": "host-receipt-1",
"reason": "Host execution requires remediation evidence.",
"recorded_at": "2026-05-28T00:00:03Z",
"outcome": {},
"evidence": {}
}A ReversalEvent records undo, counter-action, remediation, or non-reversibility evidence. It is not a rollback command and does not mutate host business truth.
Idempotency
Every evidence write requires an idempotency_key.
| Evidence | Idempotency scope |
|---|---|
ExecutionReceipt | Execution permit |
WitnessEvent | Organization |
ReversalEvent | Organization |
The success envelope reports the contract and recorded evidence kind:
{
"data": {
"contract_version": "host-evidence-v0",
"kind": "execution_receipt",
"evidence": {}
}
}Duplicate requests with the same identity return the existing evidence. Reusing a key with conflicting content returns 409 idempotency_key_conflict.
What this API does not do
This surface does not issue or verify permits publicly, sign credentials, execute host mutations, validate host-specific policy, or advance permit lifecycle automatically.
The current Golden Loop proves proposal and lifecycle reconciliation. It does not yet prove a live mutation flowing through permit issuance and this evidence API.