Ports are the typed interfaces of a data product — the defined boundaries through which it exposes and consumes data. Every data product in the Data Product Standard application has three kinds of port: output, input, and management. The model is drawn from Data Mesh, where each product owns its own interfaces instead of sharing one central pipeline.
Each port has a direction and a purpose. This page covers what output, input, and management ports do and the attributes that describe each one. It also explains how an output port on one product feeds an input port on another to form data product lineage.
The diagram below shows the full path: a data product exposes data through an output port, a data contract covers that port, and a consuming product reads it through an input port.
The three port types
A data product exposes and consumes data only through its ports. The three types differ by direction — what data moves, and which way. Each maps to an open standard: the Open Data Product Specification (ODPS) and the Open Data Contract Standard (ODCS).
| Port type | Direction | Purpose | Standard basis |
|---|---|---|---|
| Output port | Provides | What the product delivers to consumers | ODPS data access + ODCS output port |
| Input port | Consumes | What the product reads from upstream products | ODCS + ODPS |
| Management port | Operational | Monitoring, health checks, and logging | ODCS concept |
Output and input ports move the product’s data. The management port is out-of-band: it carries operational signals about the product, not the data itself.
Output port
An output port is where a product publishes data to consumers — its consumable delivery surface. It holds one or more data assets and is bound to a single technology, so one port carries exactly one delivery protocol and access model. A product can have several output ports: for example, a REST API port for applications and a reporting-export port for analysts.
Binding each port to one technology keeps its contract and access model unambiguous. A consumer reading the API port never has to reason about the export port’s format or authentication. A breaking change to the interface raises the port version, so consumers migrate deliberately.
These attributes describe an output port:
| Attribute | Description |
|---|---|
| output port type | The technology class of the port: File, API, SQL, AI, gRPC, or sFTP. |
| access format | The format consumers receive: JSON, XML, CSV, Excel, ZIP, Plain Text, GraphQL, or MCP. |
| authentication method | How consumers authenticate: OAuth, Token, API Key, HTTP Basic, or None. |
| API specification | The specification format documenting the interface: OAS, RAML, Slate, or MCP. |
| access URL | The endpoint or location where consumers reach the data. |
| specification URL | A link to the machine-readable interface specification. |
| documentation URL | A link to human-readable documentation for the port. |
| hash type + checksum | An integrity check for delivered files, such as a SHA-256 hash and its value. |
| port version | The version of the port’s interface, so consumers can track changes. |
A data contract can be attached to an output port to govern what it delivers — its schema, quality, and terms. For how contracts formalize that promise, see Data contracts.
Input port
An input port is where a product reads data from other, upstream products. It is lighter than an output port: consumers care about what your product delivers through its output ports, so input ports mainly record lineage and dependencies. An input port points at a specific upstream output port and consumes that whole port, not individual assets inside it.
Consuming the whole port means the input port inherits whatever the upstream output port guarantees, including its contract. If the producer reorganizes the assets behind that port, the dependency still holds, as long as the port’s promise is unchanged.
These attributes describe an input port:
| Attribute | Description |
|---|---|
| description | What the product reads from the upstream port and why. |
| authentication method | How the product authenticates against the upstream port. |
| access URL | The endpoint of the upstream output port being consumed. |
| specification URL | A link to the upstream port’s interface specification. |
| documentation URL | A link to documentation for the upstream port. |
| port version | The version of the upstream port this input port consumes. |
Management port
A management port is an operational endpoint for monitoring, observability, health checks, logging, and metrics. It supports the teams that run a product, not the consumers who read from it. Management ports are hidden by default, since operational signals are an operations concern rather than something consumers browse.
Platform and operations teams use these endpoints, often wiring them into observability tooling. A management port never appears in data product lineage, because it reports on the product rather than moving data between products.
These attributes describe a management port:
| Attribute | Description |
|---|---|
| access URL | The endpoint where the operational signal is available. |
| documentation URL | A link to documentation for the management interface. |
| channel | The delivery channel that carries the operational signal. |
| content type | What the port reports: Logging, Monitoring, Observability, Health Check, Metrics, or Custom. |
How ports connect data products
Data products connect to each other through ports, and data moves in one direction along a fixed path:
data asset → output port → product boundary → input port → consuming product
One product’s input port consumes another product’s output port. That producer-to-consumer link is what Dawiso draws as data product lineage, so dependencies and impact analysis stay visible across teams.
The link is consumer-initiated: the consuming product wires its input port to the producer’s output port. The producing product does not need to know its consumers in advance. Once the link exists, the producing product shows a Consumed by view that lists every downstream product reading from it.
For example, the “Sales” data product exposes a “Sales API” output port. The “Marketing insights” data product adds an input port that points at the Sales API output port. “Sales” then lists “Marketing insights” under Consumed by, and Dawiso draws lineage from Sales to Marketing insights.
These links answer two questions teams ask constantly. Before changing an output port, a producer opens its Consumed by view to see who depends on it and gauge the impact. A consumer traces its own input ports backward to see where its data originates. Lineage makes both directions navigable across the organization.
Ports and data assets
A data asset is a concrete catalog object — a BigQuery table, a Power BI dashboard, or a Snowflake view — that already exists in Dawiso. Data assets attach to a product’s output ports, not to the product directly. Each output port groups the assets that share one technology, so a Snowflake port and a REST API port stay separate.
Consumers depend on the port and its contract, not on the assets behind it. This keeps a product’s internal implementation hidden behind a stable interface: you can swap or add underlying assets without breaking consumers, as long as the output port keeps its promise. A product can move the table behind a SQL output port from one schema to another, and consumers see no change.
Group assets by how consumers use them, not by internal convenience. One output port per technology and audience keeps each contract focused and each consumer’s dependency narrow.
Port rules
A few rules govern how ports behave across a product’s lifecycle:
- Every published product has an output port. Once a product moves past the
Draftworkflow state, it must expose at least one output port. - Data assets attach only to output ports. Input and management ports never hold data assets.
- Input ports need an upstream source. An input port must point at an upstream output port before the product can reach the
Productionworkflow state. - Management ports stay hidden by default. Show them only when operational monitoring is relevant to your audience.
- Port names are unique within a product. Two ports on the same product cannot share a name.
- An asset belongs to one output port. A given data asset is published through a single output port on a single product — never through two ports or two products at once.
- A product cannot re-expose another product’s output. Assets already published by another product’s output port don’t appear when you build yours. To use them, add an input port that consumes that upstream port. This keeps one clear owner for every published asset and avoids tangled contract obligations.
Contracts, publishing, and complete lineage
A data contract defines the guarantee behind an output port. Attaching one turns the port’s delivery promise into an enforceable agreement over schema, quality expectations, and usage terms. To govern what flows through a port, see Data contracts. For the hands-on tasks — adding ports, attaching assets, and wiring products together — see Working with ports. To add the application to a Space and build a product with its ports and ownership, see The Data Product Wizard.
Lineage is only as complete as the port links behind it. If a consuming product never wires its input port to the upstream output port, that dependency stays invisible and impact analysis misses it.