# SolaceNet — Plugin registry vs gateway rail adapters

**Purpose:** Remove ambiguity between two integration surfaces in `dbis_core`.

## 1. Plugin registry (`src/integration/plugins/plugin-registry.ts`)

- **Intent:** Core-banking and ERP connectors (Temenos, Flexcube, SAP, Oracle Banking Platform).
- **Pattern:** `IPluginAdapter` instances registered by short name (`temenos`, `swift`, `iso20022`, …).
- **Use when:** Batch or API integration to a **core system** product, not necessarily a **marketplace rail** contract.

## 2. Gateway rail adapters (`src/core/gateway/adapters/`)

- **Intent:** Regulated **messaging rails** and evidence paths (SWIFT families, DTC/DTCC, TT, KTT evidence, Thirdweb contract invocation).
- **Pattern:** `GatewayAdapter` + **`gateway-adapter-registry.ts`** canonical IDs (`dbis.adapter.*`).
- **HTTP surface:** `/api/v1/gateway/rails`, `/api/v1/gateway/rails/:adapterId/health|validate|receive` (authenticated like other `/api/*` routes).
- **SolaceNet:** Optional enforcement via `SOLACENET_GATEWAY_RAILS_ENFORCE=1` and tenant resolution (`x-tenant-id` or body `tenantId`).

## 3. Bridge strategy (recommended)

1. **Do not** duplicate the same bank connection as both an unnamed `swift` plugin and a `dbis.adapter.swift-fin` rail without documentation.
2. Prefer **gateway adapters** for anything listed in `marketplace/gateway-microservices-offering.json` rails.
3. Implement a **facade service** if one physical SWIFT connection must feed both: the facade calls the single connector and exposes plugin vs gateway shapes.
4. Document the chosen path in the institutional onboarding pack.

## 4. Quantum / QPS alignment

`LegacyProtocol` in `src/infrastructure/quantum/proxy/legacy-protocol-types.ts` includes SolaceNet-extended rails so translation/compatibility APIs can reference the same protocol names where useful.

## 5. Rail name mapping (marketplace ↔ quantum ↔ adapter ID)

| Marketplace offering rail (`gateway-microservices-offering.json`) | `LegacyProtocol` (quantum) | Gateway adapter ID |
|----------------------------------|-----------------------------|-------------------|
| SWIFT FIN/MT | `SWIFT` | `dbis.adapter.swift-fin` |
| SWIFT ISO 20022 | `ISO20022` | `dbis.adapter.swift-iso` |
| SWIFT gpi | `SWIFT_GPI` | `dbis.adapter.swift-gpi` |
| DTC Settlement | `DTC_SETTLEMENT` | `dbis.adapter.dtc-settlement` |
| DTCC Family (NSCC) | `DTCC_NSCC` | `dbis.adapter.dtcc-nscc` |
| DTCC Family (FICC) | `DTCC_FICC` | `dbis.adapter.dtcc-ficc` |
| TT Route | `TT_ROUTE` | `dbis.adapter.tt-route` |
| KTT Legacy | `KTT_EVIDENCE` | `dbis.adapter.ktt-evidence` |
| Extensible Adapter SDK | N/A (integration pattern) | Add factory + ID in `gateway-adapter-registry.ts` |

**HYBX sidecars:** map per deployment in `docs/03-deployment/DBIS_RTGS_E2E_REQUIREMENTS_MATRIX.md` — not duplicated here.

## 6. Go edge gateway vs Node rails

The **Go** service under `gateway/go/` performs **generic** capability pre-checks from path/headers (`X-Capability-ID`, `X-Tenant-ID`, …). It does **not** embed the TypeScript **`dbis.adapter.*`** catalog. **Node** (`/api/v1/gateway/rails`) owns rail adapter IDs and enforcement via `gateway-rails-enforcement.ts`. Treat this as **intentional layering**: Go = edge policy cache + proxy; Node = rail semantics — or add a shared config artifact if a single edge must enumerate rails.

---

**Version:** 1.1  
**Last updated:** 2026-04-07
