Applied subject / System boundaries
Integration should preserve meaning, not just move data.
Enterprise integration is dependable when identifiers can coexist, source positions remain attributable, and consuming systems receive information with enough context to interpret it.
Review the principles01 / Definition
Movement with meaning
Enterprise integration is the disciplined passage of information across system and organisational boundaries.
Transport is only one part of that passage. The receiving system also needs to understand what an identifier refers to, which source supplied a position, what context qualifies it and what boundary governs access.
The goal is not to pretend that every source already agrees. It is to make coexistence and interpretation explicit enough for responsible consumption.
02 / Decision principles
Before implementation detail
Five questions reveal whether an integration can remain dependable.
- Identity coexistence
- Can provider, customer and domain identifiers remain usable without being mistaken for one unexplained master identity?
- Source-neutral access
- Can a consumer work with the subject it needs rather than inheriting every source table and connector-specific structure?
- Provenance and context
- Can the recipient see where information came from and the conditions needed to interpret it?
- Trust boundary
- Is it clear what is safe to expose, what remains privileged and which system is responsible at each boundary?
- Consumption fit
- Does the exposed information remain intelligible to enterprise applications, GIS workflows or intelligent systems without claiming they all need the same view?
03 / Boundary model
Preserve, organise, expose
A source-neutral view does not require source amnesia.
Source systems can retain their own identifiers and representations. An information layer can organise identity, relationships and context while keeping attribution available. Consumers then meet a subject-oriented boundary without needing to interpret every source's internal structure.
This is a decision model, not a claim that DDI supplies a named connector, credential flow or deployment topology.
04 / Trust boundary
Public is not privileged
Expose only what belongs at the consuming boundary.
Browser-delivered experiences must remain free of secrets. Credentials, ingestion, persistence internals and privileged operations belong behind an approved server-side or platform boundary.
For V0 specifically, the available authority describes a browser-safe, read-only, source-neutral public boundary. It does not justify claims about endpoint paths, credentials, connectors, SLAs or operational availability.
05 / Technical depth
Documentation integrity
No parallel API manual without the canonical contract.
A standalone developer reference is deliberately deferred. The canonical OpenAPI contract and deeper V0 technical package are not present, so a separate route would be thin or risk diverging from the authority it should represent.
Current technical evaluation belongs here at the integration-principle level and on the bounded V0 product page. Reference documentation should be added only when the canonical machine-readable contract is available.
Continue / Context
Choose the next depth