Immutable review
Each proposal receives a unique ID plus a fingerprint of its immutable action-and-parameters snapshot. Mismatches and tampering are rejected.

HUMAN-APPROVED AI WORKFLOW AGENT / LOCAL-FIRST MVP
RELAINE turns a natural-language business request into a validated task proposal, pauses for an explicit human decision, then executes exactly the reviewed action through persistent SQLite tools.

01 / PROBLEM & SOLUTION
A language model can interpret a request, but letting it write directly into business systems makes review, traceability and failure handling dangerously unclear.
Separate proposal from execution. RELAINE validates the request, asks a local model for a strict structured action, persists an immutable snapshot, then waits for human approval.
Two real actions—create_task and update_task—demonstrate the full control loop without pretending to be a general autonomous agent or a production platform.
02 / ACTUAL USER JOURNEY
The browser never supplies replacement tool arguments. Approval names the stored proposal ID and fingerprint; the backend executes the authoritative persisted snapshot.
A person describes the task outcome in ordinary language.
LangGraph validates the request and Ollama returns a Pydantic-constrained create_task or update_task proposal.
The action, parameters, rationale, proposal ID and fingerprint are visible before any business write.
Only an exact approval can claim the proposal and call the matching persistent SQLite tool.
Submission, decision, execution and recovery events remain available as append-only history.
03 / ARCHITECTURE
LangGraph owns workflow state; Pydantic owns contracts; the approval service owns trust checks; SQLite owns proposals, tasks, receipts, checkpoints and audit history. The model proposes—it never receives a tool-execution path.
04 / SECURITY, IDEMPOTENCY & RECOVERY
RELAINE is designed to fail visibly. Unsupported requests, missing parameters, malformed model output, unavailable Ollama and database failures are never re-labelled as successful proposals.
Each proposal receives a unique ID plus a fingerprint of its immutable action-and-parameters snapshot. Mismatches and tampering are rejected.
The pending-to-executing transition is guarded in SQLite so duplicate or concurrent approvals cannot claim the same proposal twice.
The business mutation and a unique execution receipt keyed by proposal ID commit in the same SQLite transaction.
Recovery finalizes a committed receipt without repeating its write, and retries only when the absence of a committed effect is provable.
Rejected, unapproved, completed, tampered and ambiguous legacy executions are never re-executed automatically.
Audit events are recorded alongside state changes where possible, while SQLite triggers prevent updates or deletions.
05 / VERIFIED RESULTS
The release passed 103 non-Ollama regression tests and genuine local inference with the configured gpt-oss:20b model. The two real Ollama tests covered a smoke path and a live HTTP end-to-end workflow.
These results verify the implemented paths and release packaging. They do not establish production security, multi-user behavior, model quality across arbitrary requests or operational reliability at scale.
06 / REAL SCREENS
Both captures come from the running local application with synthetic demonstration data. The first stops at pending approval; the second shows the persisted result and audit trail after approval.
07 / LIMITATIONS