# Data Model — 094 Assignment Operations Observability Hardening

This feature introduces **no new entities**. It strengthens how existing operational artifacts are created, deduplicated, and displayed.

## Entities (existing)

### OperationRun

Represents a single observable operation for Monitoring.

- Ownership:
  - `workspace_id` required.
  - `tenant_id` present for tenant-bound runs.
- Key fields:
  - `type`: operation type identifier (string).
  - `status`: queued/running/completed.
  - `outcome`: pending/succeeded/failed/etc.
  - `run_identity_hash`: stable identity used for active-run dedupe.
  - `context`: structured details for Monitoring (inputs, progress, counters).
  - `failures`: array of failure items with stable `code`, normalized `reason_code`, and sanitized `message`.
  - Counter-like fields may be stored in `context` depending on existing conventions.

### AuditLog

Immutable audit record for security/ops-relevant mutations.

- Scope invariant: if `tenant_id` is present, `workspace_id` must also be present.
- This spec requires exactly one audit entry per assignment restore execution.

### RestoreRun

Represents a restore execution request and its lifecycle. Assignment restores are performed under an existing restore run.

### BackupItem

Represents an item within a backup set; assignment fetch/enrichment is performed for a specific backup item.

## Relationships (conceptual)

- One tenant has many operation runs.
- One restore run should be associated with one or more operation runs depending on orchestration; this spec requires that assignment restore execution is observable via at least one operation run.
- One backup item can have a related fetch/enrichment operation run.

## State transitions

### OperationRun lifecycle

- `queued` → `running` → `completed`
- Outcome set on completion to indicate success or failure.