TenantAtlas/specs/094-assignment-ops-observability-hardening/data-model.md

51 lines
1.8 KiB
Markdown

# 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.