---
name: ewp-network
description: Use this skill when working on Erasmus Without Paper (EWP) architecture, registry/discovery onboarding, API selection, manifest design, interoperability troubleshooting, or when navigating the erasmus-without-paper GitHub specifications.
version: 1.0.0
triggers:
  - ewp
  - erasmus without paper
  - registry
  - discovery api
  - manifest
  - interoperability
  - iia
  - omobility
  - imobility
---

# EWP Network Skill

Use this skill for technical work on the Erasmus Without Paper network.

## What This Skill Covers

- Explaining the EWP network architecture and central services.
- Planning onboarding of a provider or HEI into the network.
- Working with Discovery manifests, the Registry, and manifest sources.
- Identifying which EWP API specifications apply to a business flow.
- Troubleshooting interoperability issues between EWP nodes.
- Orienting quickly inside the `erasmus-without-paper` GitHub organization.

## Core Mental Model

Start from this model unless newer primary-source docs contradict it:

- EWP is a middle-layer interoperability network.
- Business data is exchanged directly between partner nodes.
- The only centralized services are the Registration Portal and the Registry.
- Partners should consult the Registry, not scrape other partners' manifests directly.
- A node advertises supported APIs and credentials through its Discovery manifest.
- The Registry periodically reads approved manifest sources and builds a catalogue for clients.

Read [references/architecture.md](references/architecture.md) first when the task is about concepts, topology, trust, onboarding, or data flow.

## Source Order

Use primary sources in this order:

1. Confluence architecture page for the high-level model and registration flow.
2. `ewp-specs-architecture` for the normative architecture overview and cross-cutting rules.
3. `ewp-specs-api-discovery` for manifest and onboarding details.
4. `ewp-specs-api-registry` for catalogue access, caching, and lookup behavior.
5. Domain-specific API repos such as IIAs, mobilities, institutions, factsheets, or security specs.

Use [references/repositories.md](references/repositories.md) to choose the right repository before diving into details.

## Workflow

### 1. Classify the request

Decide which lane the task belongs to:

- `architecture`: concepts, topology, central services, trust model, registration flow
- `onboarding`: how to join, publish a manifest, register, or expose endpoints
- `lookup`: how a client finds a partner endpoint or validates credentials
- `domain-api`: which API spec governs IIAs, mobilities, institutions, factsheets, files, stats, or notifications
- `troubleshooting`: manifest errors, registry mismatch, version mismatch, auth mismatch, stale catalogue, broken referential integrity

### 2. Load only the needed references

- For architecture or onboarding questions, read [references/architecture.md](references/architecture.md).
- For repo selection or spec navigation, read [references/repositories.md](references/repositories.md).
- For detailed behavior, open the relevant GitHub repository README and then the endpoint/schema files it references.

### 3. Answer with EWP-specific precision

Prefer language such as:

- "The Discovery manifest is published by the provider and consumed by the Registry."
- "The Registry catalogue is what clients should query to discover partner capabilities."
- "The request payload is exchanged peer-to-peer between nodes; the registry is not a data hub."
- "This behavior belongs to the API spec, not to the registration process."

### 4. Validate assumptions

When giving guidance:

- Distinguish what is centralized from what is peer-to-peer.
- Distinguish registration, discovery, and business-data exchange.
- Name the relevant spec repository and version branch when possible.
- Flag where behavior is normative versus a practical recommendation.

## Common Patterns

### If asked how a new provider joins EWP

Explain the path clearly:

1. Publish a valid Discovery manifest over HTTPS.
2. Register the manifest through the Registration Portal.
3. Let the Registry import approved manifest sources and rebuild the catalogue.
4. Implement the business APIs required for the provider's scope.
5. Let partners discover the node through the Registry and call its endpoints directly.

### If asked how partner discovery works

Answer in this order:

1. The client knows the target HEI and desired API.
2. The client queries the Registry catalogue.
3. The catalogue reveals supported API entries, versions, URLs, and credentials data.
4. The client chooses the compatible endpoint and calls the partner node directly.

### If asked about security or identity

Anchor the answer in the specs:

- Discovery manifests declare credentials in use.
- The Registry helps clients map credentials and covered institutions.
- Actual request validation and local user authorization remain the responsibility of each node.
- Security behavior may differ by API version, so check the referenced security spec before giving implementation advice.

### If asked about conflicts or synchronization

Remember:

- EWP is distributed.
- Some APIs expose copies that can diverge across partners.
- CNR-style notifications indicate that something changed, not what changed.
- Clients should combine notifications with refresh or index/get strategies instead of assuming perfect push delivery.

## Output Style

When answering, prefer:

- one short architecture summary,
- one concrete flow,
- one list of relevant repositories or specs,
- and any implementation caveats that affect interoperability.

Do not imply that the Registry stores exchanged business records.
Do not recommend parsing partner manifests directly unless the spec explicitly requires it.
Do not blur HEI identifiers, manifest coverage, and local application users into one concept.