# Reference Appendices

## Appendix A: Canonical Pages

- [CLI](CLI)
- [API](API)
- [Diagrams](Diagrams)
- [Edition Boundaries](Edition-Boundaries)
- [Open Core Implementation Plan](Open-Core-Implementation-Plan)
- [Private Enterprise Repo Plan](Private-Enterprise-Repo-Plan)
- [Policy Engine Hardening](Policy-Engine-Hardening)
- [Approval Workflows](Approval-Workflows)
- [Evidence Hub And Attestation](Evidence-Hub-and-Attestation)
- [Agent Registry And MCP Trust](Agent-Registry-and-MCP-Trust)
- [AI Agent Enforcement And Anti-Bypass Model](AI-Agent-Enforcement-And-Anti-Bypass-Model)
- [AISPM Dashboard Roadmap](AISPM-Dashboard-Roadmap)
- [AI Security Posture Dashboard Contract](AI-Security-Posture-Dashboard-Contract)
- [AISPM CSO Report Center](AISPM-CSO-Report-Center)
- [AISPM Enterprise Live Ingestion](AISPM-Enterprise-Live-Ingestion)
- [Azure Community SaaS Deployment](Azure-Community-SaaS-Deployment)
- [Azure Trial And Enterprise Deployment](Azure-Trial-And-Enterprise-Deployment)

## Appendix B: Command Families

| Family | Representative commands |
| --- | --- |
| Core | `cavra version`, `cavra evaluate` |
| Agent | `cavra agent start`, `cavra agent exec`, `cavra agent attest` |
| Policy | `cavra policy list`, `validate`, `test`, `explain`, `sign`, `verify` |
| Approval | `create`, `list`, `approve`, `deny`, `expire`, `break-glass`, `route`, `deliver` |
| Evidence | `bundle`, `verify`, `verify-attestation`, `index`, `search`, `export-siem` |
| Registry | `agent-register`, `agent-list`, `mcp-register`, `mcp-list`, `mcp-check` |
| Ops | `stores`, `backup`, `restore`, `retention-plan` |
| Runtime | Go rollback drill and runtime governance command families |
| Release | package verification, rollout, promotion, rollback, endpoint, remediation, SLA, connector delivery |
| Demo | `cavra init claude-code`, `cavra demo before-the-agent-acts` |

## Appendix C: Glossary

| Term | Meaning |
| --- | --- |
| Agent | An AI system or coding assistant that proposes or executes engineering actions. |
| AISPM | AI Security Posture Management, the posture and reporting layer built from CAVRA evidence. |
| Approval | A human or provider-backed decision that permits or denies a routed action. |
| Attestation | A signed or verifiable statement tying an action, PR, or bundle to evidence. |
| Break glass | Emergency authorization with explicit reason, actor, and audit trail. |
| Connector | Integration that delivers or retrieves evidence, reports, tickets, alerts, or workflow records. |
| Evidence bundle | A package of decision and operating proof generated by CAVRA. |
| MCP trust | Governance model for MCP servers, capabilities, tools, and approval states. |
| Policy pack | A set of rules that decide what actions are allowed, denied, or routed. |
| Runtime authority | The CAVRA decision point that evaluates an action before it proceeds. |
| Tenant | An isolated Enterprise customer or organization boundary. |

## Appendix D: Troubleshooting And FAQ

![Troubleshooting decision tree](assets/textbook/troubleshooting-decision-tree.svg)

This appendix keeps the quick FAQ close to the reference material. For the full field playbook, use [Troubleshooting And FAQ](Textbook-16-Troubleshooting-And-FAQ).

### My action was blocked. What should I do?

Run:

```bash
cavra policy explain <action> <target>
```

Check whether the policy pack, action type, resource path, command string, Git target, or MCP trust state matches what you expected. If the action is legitimate, route it through approval rather than weakening the policy silently.

### A safe command is blocked.

The command pattern is probably too broad. Replace broad globs with narrower allow or approval rules, then run:

```bash
cavra policy validate .cavra/policy.yaml
cavra policy test --policy-pack cavra-ai-agent-baseline
```

### A risky command is allowed.

The policy pack may not contain a matching command rule, or the action type may have been normalized incorrectly. Add an explicit rule, then run `cavra policy explain` against the risky command.

### Approval is stuck.

Run:

```bash
cavra approval list --state pending
```

Confirm the route owner, expiry, provider delivery state, and escalation path. If the request is stale, expire it and ask the requester to resubmit with better context.

### Evidence verification failed.

Check the bundle path, manifest, trust root, key ID, and signature material. Regenerate the trust root only when you understand why verification failed; do not paper over a broken evidence chain.

### The sandbox does not show the expected state.

Confirm you are serving `apps/sandbox-ui` from the repository root, then hard-refresh the browser. The public sandbox is static, so it demonstrates product state and sample flows rather than connecting to private Enterprise tenants.

### AISPM says production is not ready.

Open the readiness packet and resolve blockers one by one. Common blockers include missing real connector validation, unverified report delivery, tenant isolation gaps, stale evidence, and synthetic-only runtime workflows.

## Appendix E: AISPM Report Schema Families

Public contracts include dashboard, report catalog, setup, delivery audit, operations dashboard, retention lifecycle, search and retrieval, export package manifest, schedule policy, recipient policy, approval decision, exception lifecycle, evidence room, incident packet, closure, KPI metrics, alert escalation, drilldown, remediation plan, remediation closure, executive digest, digest distribution, trial validation, operator dashboard, evaluator handoff, and publication readiness schemas.

See [AI Security Posture Dashboard Contract](AI-Security-Posture-Dashboard-Contract) for schema links and public-safe examples.

## Appendix F: Development And Testing Artifacts

Implementation and validation history is archived in [Development And Testing Artifacts](Development-And-Testing-Artifacts). Use it when you need release evidence, trial-sync records, closeout notes, validation packets, or historical implementation context.

## Check Your Understanding

1. Which appendix helps you find canonical product pages?
2. Which command family verifies evidence bundles and attestations?
3. Where should historical development and testing records live?

## What's Next

Read [Policy Language Reference](Textbook-15-Policy-Language-Reference) for complete policy syntax, then [Troubleshooting And FAQ](Textbook-16-Troubleshooting-And-FAQ), and finish with [Conclusion: The Runtime Authority Revolution](Textbook-17-The-Runtime-Authority-Revolution).