Decisions

Decision result explanation and attribution

📄️ Introduction

The Memintel App Developer API provides the full surface for task creation, execution, explainability, calibration, feedback, and task lifecycle management. All execution is deterministic. LLM processing occurs only at task creation. Every definition reference is explicit — no implicit 'latest' resolution.

📄️ Apply a calibration recommendation as a new condition version

Creates a new immutable condition version using the parameters from a calibration recommendation. Does NOT modify the existing version. Does NOT automatically rebind any tasks — rebinding is always an explicit user action via PATCH /tasks/{id}. Returns tasks_pending_rebind listing tasks still bound to the previous version.

📄️ Generate calibration recommendation for a condition

Analyses stored feedback and/or a target alert volume to recommend adjusted parameters. Returns no_recommendation for equals strategy (no numeric parameter to adjust) or when no valid adjustment exists within declared threshold_bounds. Does NOT modify the existing condition — call apply-calibration to create a new version.

📄️ Conditions

Conditions

📄️ Create a task from natural language intent

Submits a natural language intent to the LLM pipeline. The system classifies intent, resolves primitives, selects a strategy, resolves parameters, generates a concept + condition, binds an action, validates, compiles, and persists a version-pinned Task. Pass dry_run: true to preview without persisting.

📄️ Decisions

Decisions

📄️ Delete a task

Soft-deletes a task (status = deleted). Deleted tasks are inactive and skipped during execution but retained for audit purposes.

📄️ Execute concept + condition + action pipeline

Runs the full ψ → φ → α pipeline for a given entity. Fully deterministic when timestamp is provided. No LLM involvement. Use dry_run: true to simulate without firing actions.

📄️ Execution

Execution

📄️ Explain condition logic and parameters

Returns a human-readable explanation of what a condition evaluates, why its parameters were selected, and its relationship to its concept.

📄️ Explain a specific decision result for an entity

Returns a full explanation of a decision — why it fired or did not fire, the concept value that was evaluated, the threshold or label applied, and the contribution of each input signal. Supports both boolean and categorical decision outputs.

📄️ Feedback

Feedback

📄️ Get a condition definition

Retrieves a specific condition definition by id and version. Use to inspect condition logic and parameters before explaining or calibrating.

📄️ Get task details

Returns the full task definition including concept, condition, and action references (id + version for each), plus execution metadata.

📄️ List tasks

Returns a paginated list of tasks for the current workspace.

🗃️ schemas

22 items

📄️ Submit feedback on a decision

Records user feedback on a specific decision result. Feedback is stored and consumed by POST /conditions/calibrate to derive tighten/relax direction. false_positive → tighten (condition too sensitive). false_negative → relax (condition too strict). correct → no-op. Note: feedback on an equals strategy condition is stored but will always result in no_recommendation from calibrate (no numeric parameter to adjust).

📄️ Tasks

Tasks

📄️ Update a task

Updates operational task settings. Condition logic, concept definition, strategy, and action logic MUST NOT be modified here — those require the calibration flow (calibrate → apply → rebind). Allowed: condition_version rebind, delivery config, entity_scope, status.