⛔ Read this skill in full before running a decision comparison. The graph's reasoning (the IMPL/NAND/mitigation structure) is the deliverable — the ranking is the read-out.

tortoise-decide

Make a decision on the graph: the options, the criteria, the findings, the
reasons (edges), and the resulting confidence ranking all live in Tortoise —
so the decision is auditable, comparable across time, and re-runnable as new
evidence lands.

Which Tortoise are you on?

• Hosted (cloud): your agent uses the Tortoise MCP tools (tortoise_*).
  If you installed the skills via the onboarding wizard, the MCP server is
  already wired. Configuring it by hand? Use the equivalent project-scoped
  .mcp.json entry: {"type": "http", "url": "https://api.premiselabs.co/mcp/", "headers": {"Authorization": "Bearer ${TORTOISE_API_KEY}"}} — that file is committable, so it carries the env reference, never the key. A project-scope server stays ⏸ Pending approval until you approve it once — start claude in the project and allow the prompt, or run /mcp.
• Self-hosted: your agent uses the same tortoise_* MCP tools against a
  local MCP server pointed at your own FalkorDB, or runs
  graph-scripts/decide.py / the Python SDK directly.

The execution below is tool-based (MCP) — the same tool names for both
audiences. The script variant is at the end.

The 7-step workflow (authoritative)

1. Refine the decision with the user. What exactly is being decided? Write
   it as a short domain label (e.g. 2026-Q3-db-migration). Get the options
   right before anything else — the user owns the option set.
2. Research options and criteria. What are the candidate options? What
   criteria will they be judged on? What findings (evidence) are relevant?
   (For deep research, pair with the research skill; new findings land on
   the graph and connect to the decision.)
3. Check with the user: list the criteria (for value) + the options (for
   completeness) — confirm before wiring edges.
4. Connect criteria → options. For each criterion that supports or
   undermines an option, create an operator edge:
   • crit:1 -[IMPL]-> opt:a — the criterion argues FOR the option
   • crit:1 -[NAND]-> opt:b — the criterion argues AGAINST the option
5. Research IMPL/NAND MITIGATIONS to the option–criterion connections.
   Sometimes a finding NANDs an option itself ("out of stock") — but mostly
   findings mitigate the operator (the criterion is TRUE but matters
   LESS). Express fit on the operator, never NAND the option for a bad fit.
6. Optional: sub-mitigations. A mitigation can itself carry an operator
   on the edge → mitigations of mitigations (nested relevance).
7. Options can also IMPL/NAND among themselves — two go well together
   (IMPL), three are mutually exclusive (NAND) with those two.

Then run the EP computation and present the ranked options with their
confidence — plus the why: the top reasons (edges) that moved each option.

Execution (tool-based — MCP tools)

Use the Tortoise MCP tools (no local FalkorDB needed for hosted tenants; self-hosted users with a local MCP server use the same names — otherwise use the script variant below):

1. Create the nodes — tortoise_create_point per point (dedup by
   content): options → pointKind: option, criteria → criterion,
   findings → evidence; keep ids stable (opt:a, crit:1, finding:1).
   Decision parts are born LIVE with an explicit starting belief (#2199):
   omit credibility for the system starting belief (medium = Beta(3,1),
   provenance system-default, visible in tortoise_calibrate_summary), or
   pass credibility="high|medium|low" (ladder gold/high/medium/low/
   unverified) when you have a real belief — recorded set-by-author. There
   is NO promote/calibrate step in this workflow: the documented flow ranks
   on the first try.
2. Wire the edges — tortoise_create_operator for each IMPL/NAND;
   mitigation strength in [0.10, 0.50] for relevance edges (0.50 = strongest
   dampening — single source: tortoise/weights.py module docstring, #2315).
   strength is the graded DAMPENER of the operator's effective EP weight:
   w_eff = w * (1 - strength) — a 0.30 mitigation keeps 70% of the weight,
   0.50 keeps 50%; dampened, never refuted. It is NOT how true the reason is
   and is NOT fused into any prior (the mitigation POINT's own belief is
   calibrated like any decision part). EP reads mitigation_strength via
   compute_operator_weight.
3. Compute — tortoise_compute_confidence (EP belief propagation on the
   decision subgraph) → the per-option confidence.
4. Sanity — tortoise_check_structure before presenting (the graph must
   be structurally sound: no orphan operators, edges well-formed).

Output contract

Decision: <label>
Options ranked by EP confidence:
  1. opt:a  — <confidence> — top reasons: <edges>
  2. opt:b  — <confidence> — top reasons: <edges>
Mitigations applied: <n> (relevance-adjusted operators)

Self-host variant

graph-scripts/decide.py runs the same model locally against a FalkorDB
(--db URI / TORTOISE_DB_URI): --options/--criteria/--findings/--edges/ --truth-edges/--relevance-edges (JSON) or --input file.json|yaml with the
full decision definition. Same input shape as the tool-based flow. Hosted
tenants use the MCP tools above.

Anti-patterns (the corruption classes)

• ⛔ Never pass a bare aboutObject/context as a point prop — it's a
  node property, non-canonical + invisible to traversal. Wire edges
  explicitly (ID-based).
• ⛔ Never NAND an option/criterion for bad fit — express fit on the
  operator (truth vs relevance).
• ⛔ Never let operator resolution fall back to stub nodes — every edge
  source/target must be a real created point id.
• ⛔ Don't store decisions as first-class Points — the graph says "this
  state is based on these reasons"; the decision dimension is the
  decision-as-Event timeline.