Run Profile Specification¶

Status: Experimental profile for OCLP Core 0.3.0-draft.

The run profile gives an Execution portable start and terminal chronology and places it in one concrete run. It never adds a parent Execution or a dataflow edge.

Declaration¶

Declaration	Value
Profile ID	`run`
Profile version	`0.3.0-draft`
Core compatibility	OCLP Core `0.3.0-draft`
Extension surface	The `profiles.run` binding on an Execution and the Event conventions below

Every Execution that participates in a concrete run MUST carry the same binding:

{
  "run": {
    "version": "0.3.0-draft",
    "run_id": "4bb4b607-c6cc-4979-80e8-16bfc1c443c8",
    "run_name": "Nightly feature build"
  }
}

run_id is a producer-generated UUID, created once when the run begins. It is profile data, not a Core record reference and not a causal relationship. A consumer MAY use it to group the claiming Executions, but Artifact references remain the only dataflow edges.

Field	Requirement
`version`	Required; exactly `"0.3.0-draft"`.
`run_id`	Required UUID string.
`run_name`	Required concise human-readable run label.

Event conventions¶

Event type	Requirement	Meaning
`execution-started`	Exactly one, sequence `0`, no status	The Execution began.
`execution-terminal`	Zero or one, follows start, includes Core status	The Execution reached a terminal state.

A missing terminal Event represents an incomplete or still-running Execution. Events retain the Core-required execution, occurred_at, and sequence fields. Other application Events may occur between these standard events.

See spec/run.md, profiles/run-binding.schema.json, profiles/run-timeline.schema.json, and tests/profiles/run/ in this repository for the normative specification, schemas, and conformance vectors.