Share data as agreed.
Across every permitted boundary.
Datastreams turns agreements between departments, partners and service providers into one running data operation. Sources and destinations can change while purpose, permissions, delivery conditions and evidence remain explicit.
Interoperability is not unrestricted movement. Every exchange still has an identified party, purpose, policy and evidence requirement.
The agreement becomes executable
Describe who may exchange what, why and under which conditions.
A source can be an application, wallet, device, partner or public register. A destination can be another department, organisation, operational system, archive, person or approved agent. The shared definition remains understandable to the parties responsible for it.
Source
Contract
Trust
Policy
Delivery
Evidence
Hot-swappable by contract
Swap the service, not the business operation.
A source connector, identity provider, trust service, payment provider or destination can change where standards and policy allow it. The stream contract and required outcome stay authoritative.
Replace behind the contract
Map the replacement to the same accepted inputs, outputs, trust level and failure behaviour instead of rewriting downstream logic.
Control every switch
Validate, diff, dry-run and approve the new adapter or provider before the active configuration changes.
Keep an audit trail
Record the configuration version, provider, policy decision and delivery result so every exchange remains explainable after a swap.
Hot-swappable does not mean interchangeable without conditions. Legal status, certification, credential format, trust level and contractual obligations must remain compatible with the stream policy.
One runtime, different exchanges
Transport, trust and commercial conditions belong together.
The runtime does not pretend to be every issuer, trust service or payment provider. It makes their results operable as one governed data service.
Direct data delivery
Accept an event from any supported source, validate its contract and deliver it to one or many permitted destinations.
Signed data exchange
Verify the issuer, signature or seal, keep provenance attached and let policy decide whether the data may be accepted or forwarded.
Paid data service
Bind entitlement, price, payment confirmation and delivery conditions to the stream. The payment provider remains the payment rail; the runtime governs fulfilment.
Identity-bound exchange
Request only the identity or attribute needed, validate the presentation and apply purpose, consent and retention before the result enters the operation.
The EUDI Wallet inflection point
Identity becomes a verified input to the data service.
The EU wallet introduces cross-border, user-controlled presentations of identity data and attributes. Datastreams can receive the presentation result, validate it, bind it to purpose and execute the permitted exchange.
Conceptual operation
source: partner_offer requires: identity: legal_person attribute: authorised_representative signature: accepted_trust_level entitlement: active policy: purpose: contracted_exchange minimise: true destination: permitted_recipient evidence: exchange_receipt
Conceptual model, not published CLI syntax.
Clear responsibility boundary
The runtime is the operating layer, not a substitute for regulated actors.
The runtime makes the configured integration controlled and auditable. Legal compliance still depends on the applicable purpose, organisation, provider and jurisdiction.
Datastreams runtime
- Source and destination adapters
- Contract and schema validation
- Identity and trust verification hooks
- Purpose, consent and entitlement policy
- Routing, transformation and actions
- Decision evidence, inspection and recovery
Connected ecosystem
- Wallet and credential issuer
- Relying-party registration and certificates
- Qualified trust service for qualified signatures or seals
- Payment service provider and settlement rail
- Sector-specific registers and legal authority
- Destination system and its access policy
Verify
Who issued the data, who presented it, whether it is current and which trust level applies.
Permit
Which attributes, purpose, recipient, payment status and retention rule allow the exchange.
Prove
Which configuration and evidence produced the delivery, rejection or business action.
Start with one exchange that currently stops at an organisational boundary.
Map the source, recipient, trust requirement, commercial condition and proof. The runtime configuration becomes the shared contract.
Map an interoperable service