Skip to content

Open operation record · v0.4.0 · Educational reference · public draft

The AI service operation record.

A practical anatomy for proving what an AI-assisted workflow actually did. It follows the work from first contact through rules, systems, human judgment, and a verifiable end state.

A conversation is not complete merely because the dialogue ended. The record must show what was understood, what authority applied, what happened in a system, who owns any exception, and whether the intended operational outcome was reached.
Download the JSON templateDownload the audit checklist

By Koltra AI · Updated

Shared interaction session · sess_4c2aillustrative
1Operation A · RescheduleThe scheduling write and confirmation agree.Completed
2Operation B · Missing referralAccepted staff action is attributable before the operation completes.Completed after accepted human participation

If you run a practice: this is the page that shows what your morning team would see after last night’s call. Which clinic’s rules applied, what changed in the calendar, what a nurse was asked to decide, and whether the work finished. Everything below is the anatomy of that page, written so an auditor could check it.

Each execution leaves a run record: what happened during that execution and how it ended. An operation is the customer job one or more runs advance. A session is the interaction envelope; it may open or continue more than one operation.

v0.4 defines run-record evidence.

The example below groups conforming run records into two operation-level views linked to one session. It is a worked example, not a published operation schema.

The record remembers what happened. How that evidence is judged lives in the evaluation method. How evaluation works

One session can contain two operations.

A patient calls to reschedule an appointment and asks what happened to a missing referral. That is one session and two operations. Illustrative patient-access example. Not a live case.

Shared interaction session

sess_4c2a

Inbound voice. Same identity, same practice, same permissions. Two operations open. The session links them; it does not merge their outcomes.

op_a18c

Operation A · Reschedule

Completed
  1. 01
    Identify

    Identity and permitted context

  2. 02
    Apply rules

    Location and appointment constraints

  3. 03
    Update system

    Authorized scheduling write

  4. 04
    Complete

    Scheduling system and confirmation agree

Run references
run_a18c_01 Voice reschedule workflow
Operation record
Separate operation-level record linked to sess_4c2a.
Evaluation result
Completed · policy held · no handoff · no recovery required
Terminal detail
The scheduling write and confirmation agree.
op_b18c

Operation B · Missing referral

Completed after accepted human participation
  1. 01
    Create

    Missing-referral operation opened

  2. 02
    Continue

    Secure upload link sent by SMS

  3. 03
    Wait and retry

    Two-hour timeout; one reminder; duplicate protection applied

  4. 04
    Receive and hand off

    Document arrives through the secure upload; staff accepts with context intact

  5. 05
    Complete

    Document attached and the downstream workflow advances

Run references
run_b18c_01 Voice referral inquiryrun_b18c_02 Secure-upload continuationrun_b18c_03 Accepted staff handoff and completion
Operation record
Separate operation-level record linked to sess_4c2a.
Evaluation result
Completed after accepted human participation · timeout and retry recorded · secure-upload boundary held
Terminal detail
Accepted staff action is attributable before the operation completes.

Each operation keeps its own actions, runs, handoffs, terminal state, and evidence, and is judged separately under the same method. The session links them; it does not merge their outcomes or their scores.

Illustrative. Not a live case. Not production telemetry. Clinical judgment stays with the care team.

From contact to an attributable outcome.

Each section answers a different operating question. Together they show whether the workflow acted within authority and left the work complete, safely blocked, contained, or owned.

run_v040_01 · inbound voice · illustrative
  1. 01

    Trigger

    What started the work?

    Minimum fields
    • channel
    • received at
    • request type candidate
    • identity state
    • source context references

    Failure signal: The request cannot be traced to a channel, time, or permitted context source.

  2. 02

    Understanding

    What did the system understand, and what remained uncertain?

    Minimum fields
    • normalized request
    • required facts present
    • required facts missing
    • ambiguities
    • resolution state

    Failure signal: The system acts while required facts or unresolved ambiguities are hidden.

  3. 03

    Authority

    Which rule, permission, boundary, or approval governed the next step?

    Minimum fields
    • policy references
    • permitted actions
    • prohibited actions
    • approval state
    • professional judgment boundary

    Failure signal: The record cannot explain why an action was allowed, blocked, or handed to a person.

  4. 04

    System action

    What was attempted in an authoritative business system?

    Minimum fields
    • target system
    • action type
    • bounded payload summary
    • result state
    • duplicate control
    • safe evidence reference

    Failure signal: The conversation implies completion while no authoritative system action or result exists.

  5. 05

    Human handoff

    If judgment was required, who accepted the work and with what state?

    Minimum fields
    • handoff reason
    • destination role or queue
    • context attached
    • accepted at
    • acceptance state
    • next owner

    Failure signal: The system says it escalated, but no person or queue accepted ownership.

  6. 06

    Outcome

    What operational condition is true now?

    Minimum fields
    • outcome state
    • completed work
    • remaining work
    • current owner
    • confirmation state
    • follow-up trigger

    Failure signal: The interaction ended without a completed result, explicit owner, or next trigger.

  7. 07

    Run metadata

    Can the path be inspected without exposing prohibited data?

    Minimum fields
    • record id and version
    • workflow version
    • safe provider versions
    • latency if measured
    • cost if measured
    • correction history
    • privacy classification

    Failure signal: The run cannot be reconstructed, compared, corrected, or safely reviewed.

A run can end only where its evidence ends.

Fluent conversation, a sent message, or an attempted tool call is not a terminal state. Use exactly one of these outcomes.

completed

Completed

requires The permitted action appears in the authoritative system and any required confirmation is recorded.

human_owned

Human owned

requires A named person or queue accepted the full state and owns the unresolved decision or exception.

blocked_safe

Blocked safe

requires A known rule or missing authority prevented the action, and the reason and next safe step are recorded.

failed_contained

Failed contained

requires The attempt failed, partial effects were detected or contained, and the recovery owner or trigger is explicit.

unresolved

Unresolved

no completion proof No authoritative outcome or accepted owner can be proved. This state must never be reported as completion.

The fields stay stable while the judgment boundary changes.

These reference examples connect patient-access product work with an exploratory MSP context. A field pack illustrates how the record could be used; it does not announce a product or establish a deployment.

Healthcare patient access

Illustrative reference · patient-access product context

Permitted operation example
Apply declared scheduling rules to a non-clinical appointment request and record the appointment-system result.
Human judgment boundary
Symptoms, clinical questions, triage, and care guidance stay with the care team.
Completion evidence
The appointment record and confirmation agree, or a named practice owner accepted the exception.
See the healthcare context →Download the patient-access checklist →

MSP service desk

Illustrative reference · exploratory MSP context

Permitted operation example
Classify and enrich a ticket from declared customer, contract, impact, and environment context, then route it under approved rules.
Human judgment boundary
Diagnosis, customer-environment changes, and major-incident command stay with qualified technicians.
Completion evidence
The PSA record contains the priority, enrichment, routing reason, and accepted queue or technician owner.
See the msp context →Download the MSP triage checklist →

The same anatomy is drafted for four further contexts, as checklists only: legal client operations, tourism guest operations, equipment rental exchange coordination, b2b receivables dispute resolution.

Can the operation be inspected after it ends?

Use this list during product design, vendor evaluation, workflow review, or incident analysis.

  1. Define the permitted request and intended end state before the run starts.

  2. Capture the source channel, time, identity state, and permitted context references.

  3. Separate known facts, missing facts, and unresolved ambiguity before an action.

  4. Record the rule, permission, approval, and human-judgment boundary that governed the step.

  5. Keep the authoritative system action and result, including retries and duplicate controls.

  6. Require a person or queue to accept ownership when judgment or exception handling is needed.

  7. End in exactly one declared terminal state, never in an implied success.

  8. Keep privacy classification, corrections, measured latency, and measured cost inspectable without inventing values.

How to use the reference

Start with one recurring service workflow. Define the permitted end state, then test whether each of the seven sections can be reconstructed after a run. Missing fields are not automatically product failures, but missing proof of an action, owner, or end state must remain visible.

  • This is not a production event schema.
  • This is not a report of a live Koltra product run.
  • This is not a benchmark, certification, compliance claim, or performance result.
  • The fields and vertical applications are educational design material and require context-specific review.
  • Latency and cost belong in a record only when they are actually measured; the blank template supplies no synthetic values.

Apply it to one real operating job.

Reuse and adapt this reference with attribution to Koltra AI and a link to the canonical page.

Work with KoltraRead the platform architecture