Content spec — integration section (exemplar)

The 'this is how you write' contract for one section type (REQ-31). Every design/integrations > {system} section owes:

Required fields

• purpose — why this integration exists, in the client's words
• direction — inbound / outbound / bidirectional
• pattern — request-response / file transfer / event-driven
• contract — format and schema reference (or 'to be obtained from {party}')
• volumes — expected frequency and payload size, peak and normal
• error handling — what happens when the other side is down, slow, or wrong
• environments — endpoints and auth per environment, credentials by reference only

Writing guidance

State what is KNOWN with a source, what is ASSUMED as an assumption item, and what is UNKNOWN as a clarification — never prose over a gap. One section per external system; if two systems share a pattern, they still get separate sections.

Example (condensed)

CVR (Danish business register): purpose — validate customer legal entities at onboarding; direction — outbound; pattern — request-response; contract — CVR API v3 JSON; volumes — ~200/day, burst 2k at campaign launch; errors — soft-fail with manual review queue, 24h retry; environments — test + prod endpoints, API key via secret manager.

How this spec is used

Compiled into the drafting agent's briefing when it fills this section · gap analysis measures these fields, not just section presence · reviewers see this as a checklist beside the section.