Interface contracts
How one subsystem depends on another: what an interface contract holds, the requirement it becomes, and where to find it.
What a contract says
An interface contract says how one subsystem depends on another. It has a source subsystem, a target subsystem, a type and a payload, and it becomes a requirement:
| Type | Means | The requirement it becomes |
|---|---|---|
| Data | The source provides data to the target. | The source shall provide payload to the target. |
| Trigger | The source notifies the target. | The source shall notify the target when payload. |
| State | The target checks state from the source. | The target shall verify payload from the source before proceeding. |
Both ends are subsystems of the project. A system outside it, such as a payment provider, is not a contract: the Spec score checks instead that the spec names its external interfaces.
Adding a contract
In Manage Subsystems, select Add Dependency, then choose the source and the target, the type of link, and the payload. It needs two subsystems or more. Auto-detect proposes contracts along with the subsystems. The app has no form to edit a contract: change it in the chat, or have a coding agent change it over MCP.
Contracts in the requirements table
Each contract shows up as a generated interface requirement, with an id such as REQ-INT-001: under Interfaces in View All, and in the view of each of its two subsystems.
- It is read-only: it changes with its contract, and only then.
- It has no status, so the status line over the table leaves it out, and says so.
- Deleting it deletes the contract.
In the Spec score
The Interfaces area checks that each contract has a type and a payload, and has the model judge whether it specifies the payload's fields, the errors and the timing. A contract has no fields of their own for errors or timing: write them into the contract, through the chat or MCP.
For experts: interfaces and contracts
Parts built separately fail where they meet, so systems engineering defines and manages the interfaces between a system's parts in their own right: interface management, in the INCOSE handbook (3.2.4) and NASA's Systems Engineering Handbook (6.3). An interface contract is Entalpa's record of one such interface.
| In Entalpa | Based on |
|---|---|
| A contract between two subsystems | An interface between two system elements, defined with the system's architecture: ISO/IEC/IEEE 15288:2023, 6.4.4. The requirement it becomes is an interface requirement, which has a place of its own in a system requirements specification: ISO/IEC/IEEE 29148:2018, 9.5.8. |
| What each side owes the other | Design by contract (Meyer, 1992): a contract states the obligations between a client and a supplier. A State contract, where the target checks state from the source before proceeding, is close to what Meyer calls a precondition. |
| Payload fields, errors and timing | What NASA's outline of an interface requirements document asks of a software or data interface: its data standards, message timing, protocols, and error detection and correction (Systems Engineering Handbook, appendix L, 3.2.6). The Spec score's Interfaces area looks for the same. |
Where Entalpa departs from these sources, it says so:
- Software interactions only. Data, trigger and state are Entalpa's own types. Interface management in systems engineering covers every kind of interface, physical ones too.
- One record, not a set of documents. NASA keeps an interface in an interface requirements document and an interface control document, each under configuration management. Entalpa keeps one contract per interface, and the project's versions keep its history.
References
- ISO/IEC/IEEE 15288:2023. Systems and software engineering: System life cycle processes.
- ISO/IEC/IEEE 29148:2018. Systems and software engineering: Life cycle processes, Requirements engineering.
- INCOSE (2023). INCOSE Systems Engineering Handbook, 5th edition, edited by D. D. Walden et al. Wiley.
- NASA (2016). NASA Systems Engineering Handbook, NASA/SP-2016-6105 Rev2.
- Meyer, B. (1992). Applying "design by contract". Computer 25(10), 40–51.