# Cloud Operations

> Evidence for ownership boundaries, declared deployment state, exact delivery identity, observation, and reversal.

## Assessment identity

- Repository: `kinra-ai/cloud-ops`
- Revision: `dce8b08342d50e4e92c8bed4a2cb8b5e70e476d4`
- Assessment date: 2026-08-09
- Evidence class: bounded maintainer attestation; infrastructure detail remains
  private

## Domain

Cloud operations governs shared hosting declarations, service appointments,
deployment identity, observation, backup policy, incidents, and rollback
without absorbing the products deployed there.

## Mechanisms observed

- product repositories retain application source and behavior authority;
- cloud operations records exact source revisions, artifacts, host
  appointments, routes, backup contracts, and observations;
- a typed current deployment selection and service catalog must agree with
  fuller records;
- production delivery binds an exact recoverable source revision to a hashed
  artifact, configuration, binary, or image identity;
- live machines are observed rather than used as alternative authoring
  workspaces;
- mismatch and unknown remain distinct;
- post-deployment health, recovery, and rollback evidence are retained; and
- emergency deviation must be reconstructed in canonical source before later
  work treats it as current.

## What it paid to teach

Cross-system coordination does not require mirrored truth. A coordinating
system can own the appointment and observed relationship while the product
continues to own behavior and source.

This implementation materially supports `TM-MOD-005`, `TM-CUR-008`, and
`TM-CUR-009`: ownership must remain explicit, and handoff or deployment
identity must not create a second implementation workspace.

## Limits

The hosting topology, deployment classes, service schema, and operational
order are domain-specific. The repository proves infrastructure-state
discipline and exact delivery relationships; it does not establish a universal
truth-system storage model.