Given a federation scenario, produce these four artifacts in order:

1. Federation Model — who the members are, how they join/leave, what's shared vs. local
2. Trust Model — how members authenticate/authorize each other, trust anchors, revocation
3. Synchronization Flow — how state/data propagates across domains, consistency guarantees
4. Expansion Strategy — how new domains onboard, versioning, backward compatibility

Example prompt: "Design a federation for 5 hospital networks sharing patient records while keeping local databases sovereign."

Progress:
- [ ] Identify domains/members and their autonomy boundaries
- [ ] Define Federation Model (topology, membership, shared surface)
- [ ] Define Trust Model (trust anchors, credential exchange, revocation)
- [ ] Define Synchronization Flow (data flow, consistency, conflict resolution)
- [ ] Define Expansion Strategy (onboarding, versioning, deprecation)
- [ ] Stress-test against failure modes (partition, rogue member, trust anchor compromise)

1. Federation Model

• Choose topology: hub-and-spoke (central coordinator), mesh (peer-to-peer), or hybrid (regional hubs federated at top level).
• Define membership lifecycle: application, vetting, admission, suspension, expulsion.
• Draw the line between federated surface (shared schemas, protocols, identifiers) and local sovereignty (internal data models, internal policy).
• Specify the minimal shared contract (APIs, message formats, namespaces) — keep it as thin as possible.

2. Trust Model

• Pick a trust anchor pattern: single root CA, web-of-trust, or federated metadata exchange (e.g., SAML/OIDC federation, blockchain-anchored).
• Define credential issuance and rotation (certs, tokens, keys).
• Define trust levels — not all members need equal trust; tier by verification depth.
• Define revocation: how fast can a compromised member be cut off, and what's the blast radius.
• Explicitly state the threat model: what happens if one domain is malicious or breached.

3. Synchronization Flow

• Choose consistency model: strong (consensus-based), eventual (gossip/CRDT), or event-driven (pub/sub with replay).
• Map data flow direction: push, pull, or bidirectional sync.
• Define conflict resolution rules (last-write-wins, vector clocks, domain-priority ordering).
• Specify sync frequency/latency tolerance and what happens during network partition.
• Identify what MUST stay local and never sync (PII, regulated data) vs. what's federated.

4. Expansion Strategy

• Define onboarding checklist for new domains (compliance checks, technical integration test, trust bootstrapping).
• Version the shared contract (federated schema/protocol) — support N-1 backward compatibility minimum.
• Define deprecation process for retiring members or old protocol versions.
• Plan for scale: does the model still work at 10x members? Identify the topology's breaking point.

Example 1: Input: "Federate 3 university research labs to share compute results without a central authority." Output:

• Federation Model: mesh topology, each lab is a peer node, shared surface = result manifest schema + job metadata; local sovereignty = raw datasets, internal compute clusters.
• Trust Model: web-of-trust via mutually-signed X.509 certs, trust tier 1 = full result acceptance, tier 2 = quarantined/reviewed results; revocation via signed CRL broadcast to all peers within 1hr.
• Synchronization Flow: event-driven pub/sub (results published to shared topic), eventual consistency, conflict resolution = domain-priority (originating lab's result is authoritative), never sync raw datasets.
• Expansion Strategy: new lab onboards via 2-of-3 existing labs co-signing its cert; schema versioned with semver, N-1 compatibility required; deprecated labs' certs revoked and archived results retained read-only.

Example 2: Input: "Design cross-border payment federation between 4 national banking systems." Output:

• Federation Model: hub-and-spoke with regional clearing hub; shared surface = ISO 20022 message format + settlement IDs; local sovereignty = internal ledgers, KYC data.
• Trust Model: hub acts as single trust anchor issuing short-lived certs per transaction batch; tiered trust by regulatory compliance level; revocation is instant at hub, propagated via mandatory heartbeat check before each settlement.
• Synchronization Flow: strong consistency via 2-phase commit through hub for settlement finality; async eventual sync for non-financial metadata; partition handling = halt settlements, queue for replay.
• Expansion Strategy: new bank onboards after regulatory audit + hub-mediated test settlements; message schema versioned yearly aligned to ISO 20022 releases; deprecated banks get 90-day sunset with dual-running period.