Skip to content

Concepts

Five things, one direction of flow:

plugin  →  core graph  →  heuristic  →  verdict/finding  →  policy  →  plan  →  local execution
(read data)  (unify)      (classify)     (evidence)          (govern)    (sign)     (you run it)

The short version

Thing What it is Who owns it Can it change infrastructure?
Plugin Read-only collector for one system Whoever built it No
Heuristic Deterministic detector that classifies resources Core No
Verdict Core label: BLOCK, DELETE, RISK, ANCHOR, WASTE Core No
Policy CEL rule your organization wrote over the graph You No; it can block or flag a plan
Plan Ed25519-signed list of actions with evidence Core Only when you run it locally

Plugins collect

A plugin talks to one system and emits resources and relationships using canonical CRNs. It declares only read or compute capabilities. It never decides whether something is waste, risky, or removable.

Examples: a cloud account, a Postgres cluster, a Kubernetes cluster, a Git repository, a SaaS billing export.

Heuristics classify

Heuristics are compiled into core. They read the graph and set a verdict and reason on a resource — for example: idle CPU below 5% for 30 days, unattached volume, public bucket with sensitive data, or a network dependency that should never be removed.

Heuristics do not come from plugins and they do not execute anything. They are how the core answers “what is this resource’s condition?”. The result is a verdict (DELETE, WASTE, BLOCK, RISK, ANCHOR) plus evidence.

A plugin manifest has a type field, but that is catalog metadata. A source plugin cannot add or override core verdicts.

Policies govern

Policies are CEL rules written by your organization (or distributed as a data-only policy pack). They run against the graph and can require tags, forbid regions, cap spend, or block a remediation. A policy finding is an opinion with a rule ID and evidence — not a mutation.

  • cs policy validate|test|lint author and test rules.
  • Policy packs are data only: no executable code and no mutation permissions.
  • Policies can block a plan, but they cannot make a change on their own.

Plans execute locally

Core compiles a plan from findings. It preflights every action, records a journal, and signs the plan with Ed25519. Execution happens only where you run it — your machine or your VPC — through the local journaled executor. Hosted analysis is read-only.

A concrete example

  1. A plugin reports crn:example:us-east-1:prod:storage:volume:vol-1 with state=available, attached=false, tags={env: prod}.
  2. A heuristic marks it DELETE with reason “unattached for 31 days”.
  3. A policy requires an owner tag on production resources, so it adds a finding. The verdict remains DELETE; the policy is separate evidence.
  4. A plan proposes deleting the volume. It is signed and reviewed.
  5. You run cs remediate --file plan.json locally. The journal records preflight, apply, verify, and the compensation path.

That separation is the product: data collection, detection, governance, and execution are different layers with different permissions.