Incident communication

Status: customer boundary doc. Required topic incident_communication from contracts/production-admission.v0.json customer_boundary_lane.required_doc_topics.

Posture

A pilot customer learns about a relevant incident through three channels:

The membrane operation ops.incidentReceipt (staging-durable) records hash-only alert, mitigation, and communications material. The receipt is durable and citable in a proof bundle.
A direct message to the pilot’s named contact, via the channel agreed in the pilot admission record.
The status notes maintained alongside the active pilot admission record’s incident_rehearsal_ref (see contracts/production-admission.v0.json pilot_admission_lane.signed_record_required_fields).

The membrane is the authority. If the membrane records an incident receipt, the incident exists. If the membrane has not recorded it, the operations team has not yet acknowledged it and the customer has not been formally notified.

What an incident receipt records

ops.incidentReceipt captures hash-only material:

Alert hash and severity.
Mitigation hash.
Communications hash, covering the customer-facing message that was sent.
Optional reference back to the originating incident record.

Raw incident payloads are refused. The contract enforces this; see docs/api/operations.md ops.incidentReceipt and the refusal codes listed there (for example ops_incident_raw_payload_forbidden).

What customers receive

When an incident affects a pilot, the customer receives:

A message identifying the affected operations (matching the admitted_operations set in the pilot admission record).
A summary of the impact, in plain prose, without raw payloads.
A reference to the membrane receipt the customer can cite back at Gestalt if needed.
A statement of the next expected update, by time.

The message does not include raw plaintext from internal systems, raw connector responses, or biometric material.

Severity tiers

The customer-facing severity tiers are:

info — observed condition, no admitted operation impacted.
warn — degraded posture; admitted operations may emit refusals with a documented stable code.
breach — confidentiality, integrity, or availability boundary was crossed. Triggers customer notification under the agreed timeframe in the pilot admission record.

breach notifications are sent on the timeline named in the customer’s data processing terms; the membrane receipt is created before the customer message is sent.

What customers should do

On receiving a notification:

Cite the membrane receipt reference back to support if a question arises.
Pause the affected admitted operations on the customer side until the next update; the runtime may already be refusing them.
Treat refusals from the affected operations as governed; do not translate them into “system error.”