EM-TEC-03 · Subject model · W1
Interface, API and integration
Interaction contract, interface version, integration link, endpoint binding and exchange. The data schema and the transport are not equal to the business agreement.
Queued for research
Claude: not-started; Grok: not-started.
Research note, in Russian: Entire research brief pending
Subject boundary and candidate types
- InterfaceContract
- APIVersion
- Integration
- EndpointBinding
- ExchangeEvent
Deep research questions
- How to separate the logical contract and the physical address?
- Which changes are backward compatible?
- How to represent the direction, the data and the owners of the exchange?
Verifiable invariants
- An endpoint has an environment and a period
- The contract version is pinned at the consumer
- An integration does not duplicate a dataset
End-to-end acceptance scenario
An address change without a contract change and an incompatible payload change yield different migration actions.
Negative case
A new API URL is treated as a new business integration regardless of meaning.
Approaches to compare
- AISMM/WM-SFT and ArchiMate: product, system and architecture
- CSDM: business application, service and runtime instance
- SPDX/OpenTelemetry/Google SRE: delivery, observation and reliability; choose by boundary
Candidates in the live catalogue
The boundary and the reuse / extension / new model route are not chosen yet.
Result requirements
Every card is executed together with the full research contract: definitions, fields and cardinalities, lifecycle, sources, data mastership, rights, the five object facets, at least eight invariants, positive and negative examples, dependencies, migration and applicability limits.