Trusted Work Unit (TWU) Specification

01Purpose

Enterprise AI systems generate work across multiple platforms, models, and automation layers. The outputs of this work — resolved tickets, processed documents, generated content, routed decisions — carry operational and financial consequences. Yet the records describing this work are fragmented across vendor telemetry, internal logs, and disconnected application databases.

No standard exists for recording verifiable work execution across human and AI systems. The Trusted Work Unit addresses this gap by defining a deterministic, tamper-evident record format that captures what work was performed, by whom, through which systems, and with what result.

The TWU is not a log entry. It is not a metric. It is a sealed evidentiary artifact designed to survive audit scrutiny, support billing reconciliation, and provide the evidence base for regulatory compliance.

02Core Properties

A Trusted Work Unit encapsulates six core properties. Each is required. Omitting any one produces a record that cannot satisfy audit or governance requirements.

Actor Identity: The entity that performed the work — a named human agent, an identified AI model (e.g., GPT-4, Claude 3.5), or an automated system process. Actor identity must be unambiguous and traceable to a specific operator or model version.

Execution Context: The systems, platforms, and tools involved in the task. A single TWU may reference multiple systems when work spans a CRM, an AI model, and an internal routing engine.

Inputs: The data, instructions, or triggers that initiated the task. For AI systems, this includes prompts, function calls, or upstream event payloads.

Outputs: The result produced by the task — the generated response, the updated record, the routed decision, the completed document.

Timestamp: Precise execution timing for each step in the task lifecycle, establishing sequence, duration, and temporal context.

Verification Signature: A cryptographic hash computed from the complete evidence chain. This signature makes any post-hoc modification to the record detectable.

03Data Model

The following schema represents the canonical structure of a Trusted Work Unit:

{
  "twu_id": "twu_8f3a1b2c-4d5e-6f7a-8b9c-0d1e2f3a4b5c",
  "version": "1.0",
  "created_at": "2026-02-18T14:32:07.442Z",
  "sealed_at": "2026-02-18T14:32:08.118Z",
  "actor": {
    "type": "ai_agent",
    "model": "gpt-4-turbo",
    "model_version": "2026-02-06",
    "provider": "openai",
    "organization_id": "org_acme_corp"
  },
  "context": {
    "source_system": "zendesk",
    "source_event_id": "ticket_evt_991827",
    "downstream_systems": ["salesforce", "internal_routing"],
    "workspace_id": "ws_prod_support"
  },
  "input": {
    "type": "customer_inquiry",
    "content_hash": "sha256:a1b2c3d4e5f6...",
    "metadata": {
      "channel": "chat",
      "priority": "high",
      "language": "en"
    }
  },
  "output": {
    "type": "resolution",
    "content_hash": "sha256:f6e5d4c3b2a1...",
    "outcome": "resolved_without_escalation",
    "quality_score": 0.94
  },
  "attribution": {
    "ai_contribution": 0.82,
    "human_contribution": 0.18,
    "method": "time_weighted_edit_significance"
  },
  "evidence_chain": [
    {
      "step": 1,
      "actor": "system",
      "action": "ticket_received",
      "timestamp": "2026-02-18T14:30:12.003Z"
    },
    {
      "step": 2,
      "actor": "ai_agent",
      "action": "response_generated",
      "timestamp": "2026-02-18T14:30:14.227Z"
    },
    {
      "step": 3,
      "actor": "human_agent",
      "action": "review_approved",
      "timestamp": "2026-02-18T14:31:58.891Z"
    },
    {
      "step": 4,
      "actor": "system",
      "action": "resolution_delivered",
      "timestamp": "2026-02-18T14:32:01.114Z"
    }
  ],
  "verification": {
    "algorithm": "sha256",
    "sealed_hash": "sha256:7c8d9e0f1a2b3c4d5e6f...",
    "evidence_hash_inputs": [
      "actor",
      "context",
      "input.content_hash",
      "output.content_hash",
      "evidence_chain",
      "attribution"
    ]
  }
}

Each field serves a specific evidentiary purpose. The separation of content hashes from actual content allows verification without exposing sensitive data.

04Execution Lifecycle

A TWU progresses through four phases:

1.Initiation: A task is triggered — a ticket arrives, a prompt is submitted, a workflow fires. The system captures the input event and begins assembling the evidence chain.

2.Execution: Work is performed by one or more actors. Each step — AI generation, human review, system routing — is recorded as an evidence event with actor identity and timestamp.

3.Sealing: Upon task completion, the full evidence chain is assembled. A cryptographic hash is computed from the concatenated evidence inputs. The record is sealed and becomes immutable.

4.Persistence: The sealed TWU is written to the work ledger. It is now available for query, replay, reconciliation, and compliance reporting.

The lifecycle is deterministic. Given identical inputs and execution sequences, the same sealed hash is produced. This property enables independent verification: any party with access to the evidence chain can recompute the hash and confirm the record has not been altered.

05Integrity Model

TWU integrity relies on hash-based sealing. The verification signature is computed from a defined set of evidence inputs — not from a summary or metadata layer, but from the actual evidence chain that constitutes the work record.

The hash function (SHA-256) operates on the ordered concatenation of: actor identity, execution context, input content hash, output content hash, the full evidence chain, and attribution calculations. Modifying any single element — changing a timestamp, altering an attribution percentage, inserting a step — produces a different hash.

This makes TWUs tamper-evident by construction. An altered record cannot produce the original hash. An auditor can verify integrity by recomputing the hash from the evidence chain and comparing it against the stored signature.

The integrity model does not require a blockchain or distributed consensus mechanism. It requires a deterministic hash function and an immutable storage layer. The simplicity is deliberate: the fewer moving parts in the verification infrastructure, the fewer points of failure.

06Example TWU

Consider a customer support interaction handled by an AI agent with human oversight:

A customer submits a billing dispute through chat. The AI agent retrieves account history, generates a resolution recommendation, and drafts a response. A human reviewer approves the response with minor edits. The resolution is delivered to the customer.

The resulting TWU captures:

Actor: AI agent (GPT-4 Turbo) with human reviewer (Agent ID: sup_agent_442)

Context: Zendesk ticket #991827, routed through internal escalation engine

Input: Customer message (content hash preserved, raw text excluded from TWU for privacy)

Output: Resolution delivered, outcome classified as "resolved_without_escalation," quality score 0.94

Attribution: 82% AI contribution (response generation, account lookup), 18% human contribution (review, minor edits)

Evidence Chain: Four steps — ticket received, response generated, review approved, resolution delivered — each with actor identity and timestamp

Sealed Hash: SHA-256 computed from the complete evidence chain, verifiable by any party with access to the evidence inputs

This TWU can be used to verify the interaction occurred as described, reconcile vendor billing for the AI agent's involvement, demonstrate human oversight for compliance purposes, and attribute work accurately between human and AI actors.

07Enterprise Use Cases

TWUs serve three primary enterprise functions:

Audit and Compliance

When regulators or internal auditors request evidence of AI system behavior, TWUs provide the evidentiary unit. Each TWU is a self-contained, verifiable record that answers: what happened, who did it, and can we prove the record is authentic. This is the foundation of AI audit trail infrastructure.

Billing Reconciliation

When AI vendors invoice for automated interactions, TWUs provide independent verification. The enterprise's work ledger contains sealed records of every completed task. Discrepancies between vendor claims and verified completions become quantifiable and actionable.

Attribution and Governance

TWUs enable precise measurement of human and AI contributions to completed work. This supports workforce planning, automation ROI calculation, and governance reporting — based on verified evidence rather than vendor assertions.

08Relationship to AI Governance

AI governance frameworks — the EU AI Act, NIST AI RMF, emerging state-level AI legislation — require organizations to maintain records of AI system behavior, demonstrate human oversight, and produce evidence for regulatory review.

TWUs provide the evidentiary infrastructure these frameworks require. They do not replace policy documents or risk assessments. They provide the operational evidence that policies were followed, oversight was applied, and outcomes were verified. This is the distinction between governance as documentation and governance as infrastructure.

Without verifiable work records, governance is assertion. With TWUs, governance is evidence.