A record of what your software found, and what you decided to do about it
When software runs unattended, collecting logs is the easy part. The hard part is knowing which findings matter, who looked at them and what was decided. Recordant is a self-hosted product that turns logs and code changes into operator briefs and keeps findings and decisions in a ledger that lives outside the system it observes.
At a glance
Project: My own software product
- Type: Self-hosted diagnostic and decision-record tool for software operators
- My role: Product design, extraction from the original system, development, packaging and release
- Status: Self-hosted beta; version 0.2.2 published on PyPI and listed in MCP directories
- Built with: Python 3.11+; MCP SDK; optional Anthropic, OpenAI and Gemini adapters; pytest
- Invention: Related U.S. provisional patent applications have been filed
From an internal tool to a product
Recordant started as the diagnostic layer inside Mentor Sentinel, my paper-trading research platform. It was the part that watched the system and reported what it found. That job turned out to be useful well beyond one platform, so I extracted it into a standalone product any operator can run on their own infrastructure.
Briefs instead of raw logs
Recordant reads logs and code changes and turns them into operator briefs: short, structured summaries of what happened and what needs attention. An operator can start the day with a readable brief instead of digging through output.
From finding to follow-through
Recordant brings together logs, telemetry and code changes to produce a report on every review cycle. High-priority findings can include a ready-to-use fix prompt for an engineer or coding agent. Later cycles look at the changelog and observed behavior to check whether the fix landed and held.
The operator stays in charge of the work. Recordant observes and reports; the team applies the changes. That separation keeps the review independent of the software being watched.
A decisions ledger
Findings are only half the story. Recordant tracks each one in a decisions ledger: whether it has been acknowledged, accepted as a known risk, or asserted as resolved. Over time the ledger becomes a history of how the system was run, kept separate from the system itself, so the record doesn't depend on the health of the thing being watched.
Seven MCP tools
MCP, the Model Context Protocol, is a standard way for AI assistants to work with other software. Recordant provides seven MCP tools, so an operator working through an AI assistant can:
- Review briefs, current status and digests
- See open items that still need a decision
- Record acknowledgments, accepted risks and resolution assertions
The AI assistant reads and records through the same ledger an operator would use directly, and every decision stays traceable.
Choose your model provider
Optional adapters connect Recordant to Anthropic, OpenAI or Gemini models, so operators can use a provider they already work with. The adapters are optional, and the core record-keeping runs either way.
Packaged and published
Recordant is published on PyPI as version 0.2.2 and listed in MCP directories, including Glama. It's distributed under a license, with details on the Recordant page at mentorsentinel.ai. Getting it there meant packaging, documentation, automated tests with pytest and a public release process, the same work any piece of software needs before other people can depend on it.
Technology and what it does here
Python 3.11+: The core product
- MCP SDK: The seven tools AI assistants use to read and record findings
- requests: Communication with outside services
- Anthropic, OpenAI and Gemini adapters: Optional connections to the operator's chosen model provider
- pytest: Automated tests behind each release
Automated systems you need to keep an eye on?
If your business depends on software that runs on its own, I can build tools that make its findings readable and its decisions traceable, either with Recordant or with something designed around your systems.