Skip to content
Mitchel Carson

Active development · Case study

Harmony

An automated decision system with bounded LLM autonomy

Active development

KeywordsPython · scikit-learn · SQLite · React · AWS

Summary

Problem and impact

Problem

LLMs are useful for research and analysis, but an automated decision system should not let them act on their own. Harmony is a financial decision pipeline designed so that every step is declared and logged, and every consequential action waits for a human.

Impact

Harmony is an active Python project built as an explicit state graph with declared action paths and tamper-evident logging of each step. LLM research and analysis are confined to advisory nodes that can flag or veto but cannot execute.

Case study

Approach, architecture, evaluation, delivery

01Project Goals

  1. Built the decision pipeline in Python, scikit-learn, SQLite, and React as an explicit state graph with declared action paths.
  2. Logged each step in a tamper-evident record so every decision can be reviewed.
  3. Confined LLM research and analysis to advisory nodes that can flag or veto but cannot execute.
  4. Required human approval for each consequential action.
  5. Designed an isolated AWS environment for reproducible CPU/GPU research experiments, with local tools to control runs and review results.

02Architecture Decisions

  1. An explicit state graph defines each step of the decision pipeline and the action paths between them.
  2. LLM research and analysis run in advisory nodes that can flag or veto a decision but cannot execute one.
  3. Built with Python, scikit-learn, SQLite, and React.

03Evaluation Methodology

  1. Tamper-evident logging of each step.
  2. Human approval is required for each consequential action.
  3. No live-execution or investment-performance claim is part of the current scope.

04Delivery and Operations

  1. An isolated AWS environment for reproducible CPU/GPU research experiments.
  2. Local tools control runs and review results.

05Current Scope

  1. An explicit state graph with declared action paths.
  2. Tamper-evident logging of each step.
  3. Advisory LLM nodes that can flag or veto but cannot execute.
  4. Human approval required for each consequential action.

06Design Principles

  1. Boundaries belong in the architecture, not in a model’s confidence.
  2. Declared action paths make it possible to say exactly what the system can and cannot do.
  3. Tamper-evident logs make every decision reviewable after the fact.
  4. Performance claims require forward testing, not only historical simulation.
Back to projects