About logging
The Log belongs to the harness. A process does not write it, configure its destination or change its event families. It supplies the facts the harness needs to write it.
A process cannot redefine what a common event means. The Log is an audit and telemetry record; it never authorizes or recovers a Run.
How it works
- 1
The process declares its facts
For every common event it says how its own objects map to the common identities, and what process facts it attaches.
- 2
The harness emits the event
The harness function that owns each act builds, validates and correlates the common event. Gate results are written as
gate.evaluated, for generic and process-specific gates alike. - 3
The Log delivers it
The event goes to the destination the team set under
logsin Configuration: a folder or a server. - 4
Who does what
| Concern | Owner |
|---|---|
| Event families and their meaning | Harness, fixed |
| Emitting, validating, delivering and correlating common events | Harness, from the function that owns each act |
Where events go (logs: a folder or a server) | The team, in Configuration |
| Identities and declared payload schemas for each event | Process |
| Its own namespaced events | Process (optional) |
| Gate results | Harness, as gate.evaluated, for generic and process-specific gates alike |
Required event families
run.started / paused / resumed / completed / failed / cancelled / exhausted
intent.created / intent.amended
execution.started / paused / resumed / completed / failed / cancelled / exhausted
execution.usage
change.produced / change.revised
evidence.completed / invalidated
review.requested / completed / invalidated
review.finding_recorded
decision.recorded / invalidated
gate.evaluated
effect.requested / committed / reconciled
handoff.raised / resolved
human.intervened
process.version_selectedWhat every event carries
event_id, timestamp, process_id, process_version, policy_version,
run_id, intent_id, intent_version, execution_id, attempt,
change_id, base_revision, head_revision, patch_identity, actor, source_system,
correlation_id, outcome, provenance strength and safe payloadUsage records tokens, wall time and cost per Execution.
What a process must declare
- Identities. For every common event, how its own objects map to the identities above: its task to
intent_id, its review round to the Review identity, and so on. - Payload schemas. The schema of any process facts it attaches to common events.
- Its own events, if any. Namespaced under the process (for example
vinaya.), versioned, with a schema.planning. * - A mapping table. Which of its moments fire which common family, and which families it does not produce, with how readers derive them.
Conformance
The events the harness emits must hold enough contract data for Mission Control in Studio and for comparable statistics in Telemetry, without process-specific hidden data. Conformance checks this.
Each process documents its side
A process documents how it fulfils this contract on its own Integration › Logging page. For the Vinaya process, see Logging.
Configuration
None for the process. The team sets the destination under logs; see Log and Delivery.