Service Definition
What it is
A Service Definition is a standing, reusable, versioned definition of a service or offering. It is the supply-side counterpart of a one-time Intenture: where an Intenture explicates a single intent to be realized once, a Service Definition explicates a capability that can be offered and instantiated many times.
Introduced in In++ v2.1, it is a new core peer-class, sitting alongside Intenture, Knowledge Card, and Realization Artifact. Core Entities count moves from 22 to 23.
> Why it exists: the language already had a standing KNOWLEDGE side (Knowledge Card) but no standing OFFERING / CAPABILITY side. Every catalog of services was a dangling reference - domain artifacts had to point at services by code, but the core had no supply-side class and no version-safe way to record which version of a service a finished engagement actually received. Service Definition fills that ontological gap.
Structure
A Service Definition borrows the Intenture 'core_definition' (its semantic heart, universal across domains) and adds a neutral 'service_profile' (the structure of an offering, with no domain vocabulary baked in).
| Slot | Source | Purpose |
|---|---|---|
| 'core_definition' | Borrowed from Intenture | intent / object / value / constraints / expected_output - the semantic heart of the service |
| 'service_profile' | New in v2.1 | provider / performers / measurement / sla / cost_model / pricing - structure of the offering |
| 'service_type' | Namespaced identifier | type identifier, domain-defined (parallel to 'realization_artifact_type') |
| 'code' | Optional | stable catalog handle that consuming artifacts reference; scheme is domain-defined |
| 'lifecycle_state' | Shared vocabulary | Draft / Active / Stale / Superseded / Archived (same as Realization Artifact) |
| 'fields' | Open object | domain-specific data not covered by neutral slots |
> No enums in the profile. The 'service_profile' carries no domain enums. A pricing 'model' is a free string in core; the allowed vocabulary is registered by the domain manifest.
Clean separation of layers (core vs domain)
The core defines structure; the domain defines vocabulary - exactly the pattern already used for Knowledge Card Types and Realization Artifact Types.
- 'service_type' is a namespaced identifier (for example 'inspark:ClientService'), parallel to 'realization_artifact_type'. The domain registry defines its semantics.
- All value sets - audience values, code schemes, pricing model names, KPI and process bindings - are domain extensions, declared in namespace manifests.
- Domain-specific structure that the neutral slots do not cover lives in the open 'fields' object.
Class to instance: the new relation axis
In++ v2.1 adds two semantic formulas - 25 and 26 - for a relation axis the core did not previously have: class to instance.
| Relation | Connects | Axis |
|---|---|---|
| 'realizes' | artifact to intent | the same thing being realized |
| 'references' / 'informed_by' | artifact to knowledge | citation / knowledge |
| 'contains' (composition) | whole to part | one decomposition tree |
| 'instantiates' / 'instantiated_by' | class to instance | a standing definition and its per-use instances |
Version pinning
Version handling is built into the relation. Each instance records the definition version in force at the moment of realization, so that the evolution of a service never retroactively changes the promise (or measurement) of a finished instance.
| Instance state | Pinning | Behavior |
|---|---|---|
| Active | Soft pin | definition updates may flow into the instance while it is in progress |
| Completed | Hard snapshot | immutable - the Explication Record pattern; the version is frozen at completion |
> Historicity: the same mechanism that records a versioned intent (Explication Record) records which version of a service a completed engagement received. Definition evolution moves the offering forward without rewriting history.
Reference implementation
The reference implementation is the Inspark Service Catalog. Inspark registers two service types - 'inspark:ClientService' and 'inspark:CreatorService' - via the domain profile 'inspark-service.schema.json', with catalog instances such as 'services/inspark/C-01'. Consuming Inspark artifacts (CI, SP, IRS) reference catalog services by code and instantiate them through the version-pinned 'instantiated_by' relation.