> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt
> Use this file to discover all available pages before exploring further.
# How Operations Work
Your customers run your software inside their own cloud accounts.
You have no SSH keys, no kubectl context, no AWS credentials. When
something goes wrong (a pod crash-looping, a disk filling up, a
backfill that needs kicking) you cannot just `ssh` in.
Operations is the surface that bridges that gap. You ship vetted
**templates** to your customers, submit a request to run one against
one of your customer's appliances, and your customer reviews and
approves the request through a web link. The command runs inside
their appliance, the output is held encrypted in the appliance's
secret store, and your customer signs a release before you see
anything.
## The four entities
Operations works in terms of four objects. Knowing what each one is
makes the rest of the docs much shorter.
| Entity | What it is |
| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Template** | A small file you author (`*.tensor9.tf`, `*.t9.sh`, or `*.t9.kubectl`) describing one runnable operation: its body, declared data access, variables, and required permission tier. |
| **Source** | A Git repository whose templates are auto-imported into your control plane. You re-sync to pull new and modified templates as the repo evolves. |
| **Ops command** | A single submission of a template against a single customer appliance, with values bound for the template's variables. Runs through a state machine from submission to released output. |
| **Pre-approval** | A customer-signed manifest that lets you run a specific template against a specific appliance up to N times within a validity window without per-command approval. |
Templates and sources are write-once authoring artifacts. Ops commands
are the per-execution objects. Pre-approvals are an optional
optimization your customer can apply on top.
## The four-step lifecycle
Every ops command moves through the same shape, regardless of which
template flavor it uses or which appliance it targets:
Your customer reads the template description, the declared data-access
tags, your justification reason, and the exact command body and
variable values. They pick Approve, Reject, or close.
On approval, the appliance prepares to execute. Pre-approved
templates skip Steps 1 and 2 silently.
The command body runs inside the appliance's sandboxed working
directory. Output (stdout, stderr, exit code) is captured and
encrypted with a per-command key the appliance holds in its vault.
Your customer reviews the decrypted output (decrypted on the
appliance, which lives in their own cloud account under their IAM),
then signs an Ed25519 release manifest. Only after the signed release
does the control plane forward the plaintext output to you.
The control plane never sees the plaintext output before release; you
never see ciphertext. Every transition is signed, and the chain is
verifiable independently with `tensor9 ops command audit verify`.
## What your customer sees
When you submit an ops command, your customer is sent (via your
existing notification channel) a unique `/support/` web link
to their [Customer Portal](/fundamentals/key-concepts#customer-portal). Clicking the link opens a guided approval wizard where they review the command details, approve or reject it, watch it execute, and then sign a release to share the output with you.
Your customer can also review and approve pending operations from the **Operations** section of their Customer Portal.
You never see your customer's portal session. The only thing that
crosses the boundary is the plaintext output (and only after your
customer signs the release manifest).
On your side, you can track the status of ops commands in the **Vendor Portal** under **Operate → Commands**, or via the CLI with `tensor9 ops command retrieve`.
## Where to go next
| If you want to... | Read |
| ------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| Author a template (file format, variables, permission tiers, data-access tags) | [Authoring templates](/fundamentals/operations/templates) |
| Maintain a Git repo of templates as a re-syncable source (the `cmdlib` pattern) | [Git template sources](/fundamentals/operations/sources) |
| Submit and track an ops command against your customer's appliance | [Running commands](/fundamentals/operations/lifecycle) |
| Let your customer pre-approve a template once for repeated runs | [Standing pre-approvals](/fundamentals/operations/preapproval) |
| Understand the keys, signatures, and audit guarantees underneath | [Security model](/fundamentals/operations/security) |
## A minimal end-to-end
To make the rest of the docs concrete, here is the shortest possible
path from "no templates yet" to "you see released output":
```bash theme={null}
# 1. Register a Git repo of templates as a source
tensor9 ops template source create \
--sourceType GitHub \
--sourceUrl https://github.com/tensor9ine/cmdlib \
--appName my-app \
--sourceName cmdlib
# 2. Submit one of those templates against a customer's appliance
tensor9 ops command create \
--appName my-app \
--customerName acme-corp \
--template linux-disk-usage \
--vars MOUNT_PREFIX=/var/lib/myapp \
--commandName check-myapp-disk \
--reason "investigating disk pressure"
# 3. Your customer follows the /support/ link sent to them.
# Watch lifecycle progress while you wait:
tensor9 ops command retrieve --appName my-app --commandName check-myapp-disk
```
Each of those three commands is unpacked in detail on the
corresponding subpage.