Sub-networks and cross-network recognition

From the white paper: section 6 says that whether a credential issued in one country is accepted in another is a governance decision, not a technical one, and that automated recognition between networks is still to be built; this page explains both halves.

One platform, many sub-networks Live. The Civitas platform hosts white-labeled sub-networks today. An ecosystem operator gets its own branded network on the shared platform, with its own administrator, its own admitted services, and a statistics view of aggregate, anonymized activity across the sub-network: the visibility a national regulator or a lead implementing partner needs, without access to any individual's data. This is production code, running now.

Per-country registries are a design, not a build Research: no code. The target model scopes each sub-network to a jurisdiction (illustratively, civitas:ke:* for Kenya, civitas:co:* for Colombia) under a global governance layer, with each administrator governing a trust registry of its own: which entities are admitted as issuers or verifiers, which schemas are recognized locally, which connectors are integrated. That is what would let a government control who issues and verifies inside its borders without Civitas in the loop. Nothing jurisdiction-scoped exists yet. The one trust registry In build: on the Stellar test network serves the whole network, and every service registered on it today is recorded as global, not country-scoped.

Verification already crosses networks. Every sub-network runs the same credential rail, today AnonCreds over Hyperledger Indy, so a verifier in one sub-network can confirm that a credential issued in another is genuine and not revoked, with no custom integration. The property holds by construction, and it survives the migration to the open-standards stack (OID4VCI/OID4VP and W3C Verifiable Credentials, first standards-compliant releases planned for early 2027), because the migration replaces one shared rail with another shared rail.

Acceptance is a governance decision. Whether a Colombian verifier accepts a Kenyan-issued credential for a given purpose is a policy decision of the accepting side: its regulator, its business rules, its risk appetite. It is separate from cryptographic validity, and deliberately so. Today acceptance is negotiated case by case between implementing partners and regulators, the same way credential acceptance is negotiated in any cross-border context. No credential issued through Civitas has yet been accepted for a regulated KYC decision in a live deployment.

The recognition layer Research: standards chosen, nothing built. The missing piece is automated recognition: a machine-readable, queryable way for one sub-network to publish which other sub-networks' issuers and schemas it accepts, and under what conditions, so that acceptance does not require a bilateral arrangement between every pair of networks. Civitas intends to build this on standards that already exist rather than on a protocol of its own: the Trust Registry Query Protocol (TRQP v2.0, approved by the Trust over IP Foundation and deployed in the Ayra Trust Network) for recognition queries, and OpenID Federation 1.0 (final since February 2026) as the federation surface, both served over the on-chain registry state by the same trust-layer services (the exporter and verifier extension described on the licensing page). The registry query surface the platform runs today is internal catalog visibility, not this gateway. The trust-gateway work sits on the funded roadmap for 2027. The risk is political at least as much as technical: the recognition standards are young, national trust frameworks recognize one another slowly, and no two regulators will write the same conditions, so the first implementations are likely to be bilateral profiles rather than one general mechanism.

What a pilot has to show. One bilateral case, end to end:

• a verifier in one sub-network accepting an issuer from another through a signed recognition query;
• a published governance agreement behind that query;
• a named legal entity on each side;
• the data-protection responsibilities of each side written into that agreement.

Until that is demonstrated, cross-border acceptance remains a per-partner negotiation, and Civitas claims nothing more for it.

Status, 2026-10-01: white-labeled sub-networks with their own administrators run on the production platform; the single trust registry behind them runs on the Stellar test network; per-country registries and the recognition layer are not built, and cross-border acceptance is arranged partner by partner.