DEV Community: AI Tool Research Lab

How to build AI products on top of deterministic domain rules

AI Tool Research Lab — Sun, 09 Aug 2026 07:09:21 +0000

Domain-specific AI products often fail in one of two ways. They either ask a language model to calculate facts it was never designed to calculate, or they hide a deterministic rules engine behind an answer that users cannot audit.

A better architecture separates computation from interpretation.

The two-layer model

The first layer produces facts from explicit inputs. The second layer explains those facts in natural language.

For a calendar, financial calculator, medical scoring rule, or traditional charting system, the first layer should be deterministic whenever the domain permits it. The same input should produce the same structured output. Intermediate values should be visible, testable, and versioned.

The AI layer should not silently recalculate those facts. It should receive a structured snapshot and answer questions about it.

A simple data flow looks like this:

Validate input and normalize time, location, units, and locale.
Run a deterministic domain engine.
Store both the result and the calculation settings.
Build an interpretation context from selected facts.
Ask the model to explain, compare, or summarize within clear boundaries.
Show the underlying facts next to the generated language.

Why this matters for specialized calculators

Consider a BaZi chart. Solar-term boundaries, birth time, location, time-zone handling, and the displayed Four Pillars are rule-based facts. If a language model guesses them directly, a fluent answer can still be internally inconsistent.

In a system such as the Traditional Chinese BaZi calculator, the calculation should remain reproducible while AI interpretation stays optional. Users can inspect the chart first, then decide whether they want a narrative explanation.

Qi Men Dunjia has the same architectural requirement. A Qi Men chart calculator must establish the time and nine-palace structure before an AI layer discusses patterns or decision factors. The model should interpret the supplied chart, not invent a different one halfway through the response.

Treat provenance as product data

A structured output should include more than the headline result. It can also carry:

normalized input values;
time-zone and location assumptions;
rule or algorithm version;
relevant boundary conditions;
confidence or uncertainty flags;
a list of facts exposed to the language model.

This provenance makes debugging possible. When a user reports a wrong answer, the team can determine whether the problem came from input normalization, the rules engine, context assembly, or the model response.

Test the seam, not only each layer

Unit tests can prove that the rules engine handles known cases, and prompt evaluations can score explanation quality. The most expensive failures often appear at the seam between them.

For example, a correct structured result may be mapped to the wrong prompt field. A locale transformation may change a date. A summary step may drop a boundary flag. An AI response may refer to a value that was never present in the supplied context.

Integration tests should therefore capture the exact structured payload passed to the model and verify that generated claims are grounded in it.

Design the interface around verification

The UI should let users distinguish three things:

calculated facts, produced by the deterministic engine;
assumptions and settings, chosen by the user or system;
interpretation, generated or written about those facts.

This distinction is more useful than a generic AI disclaimer. It shows users what can be reproduced and what remains interpretive.

The general pattern

The same architecture applies beyond metaphysical calculators. Tax estimators, eligibility tools, engineering calculators, scoring systems, and compliance checkers all benefit from a stable rules layer with an optional language layer.

Use code for what must be consistent. Use AI for what benefits from explanation. Keep the boundary visible.

Why audio-to-MIDI needs more than one workflow

AI Tool Research Lab — Sun, 09 Aug 2026 07:07:28 +0000

Audio-to-MIDI is often described as a single machine-learning problem: feed audio into a model and receive notes. In practice, that framing hides the decisions that matter most.

A clean monophonic melody, a piano recording, and a full mastered song do not fail for the same reasons. Treating them as one workflow produces impressive demos and frustrating real-world results.

Start by classifying the source

Before transcription, ask three questions:

Is the signal monophonic or polyphonic?
Is the target instrument isolated or mixed with other sources?
Does the user need a rough musical sketch or an editable performance?

A monophonic lead has one dominant fundamental at a time. A piano can contain many simultaneous notes with long overlapping decays. A full mix adds drums, vocals, bass, reverb, compression, and mastering artifacts. These inputs need different preprocessing, confidence thresholds, and post-processing rules.

Separation can matter more than the transcription model

When the target instrument is buried in a mix, transcription quality is limited by what reaches the note detector. A larger model cannot recover every detail that has already been masked by other sources.

A practical pipeline therefore separates the problem into stages:

decode and normalize the audio;
isolate or emphasize the target source when possible;
estimate note onsets, offsets, pitch, and velocity;
remove short false notes and merge unstable fragments;
expose the result for human correction.

This also explains why a WAV workflow can behave differently from an MP3-to-MIDI workflow. Lossy encoding can smear transients and introduce pre-echo around attacks. For material where note onset timing matters, the uncompressed WAV-to-MIDI path preserves more of the signal the detector needs.

Confidence should influence the output

Many systems convert every local pitch estimate into a MIDI event. That maximizes recall but often creates a dense cloud of tiny notes. A more usable workflow treats confidence as a control signal.

For example, lower-confidence events can be shortened, suppressed, or presented as candidates for review. Adjacent fragments with compatible pitch and timing can be merged. Extremely short notes can be filtered unless the source is percussive. The correct thresholds depend on the instrument and the user's goal.

This is not merely cleanup. MIDI is an editable symbolic representation, so usability matters as much as raw note accuracy. A result with slightly fewer correct notes can be more valuable if it has stable timing and is easy to repair.

Keep a human in the loop

Audio transcription is rarely a final export. Musicians usually want to change tempo, correct a pitch, quantize selected notes, or move the result into a DAW.

That is why an online MIDI editor belongs in the same workflow as transcription. The model produces a structured draft; the editor lets the user verify and adapt it. This is especially important for polyphonic recordings, expressive timing, bends, and audio with heavy effects.

Design two workflows, not one

A useful product can expose at least two modes:

Fast sketch: optimized for a clean solo phrase and immediate playback.
Editable production draft: optimized for source separation, multitrack structure, confidence-aware cleanup, and manual correction.

The first mode minimizes friction. The second acknowledges uncertainty and gives the user control. Mixing both into one button tends to produce an interface that is simple but an output that is difficult to use.

The broader lesson

Machine-learning products improve when the workflow is designed around the structure of the input, not only the capability of the model. For audio-to-MIDI, the decisive questions are often upstream and downstream of inference: what signal was provided, what should be isolated, what uncertainty should be preserved, and how will a musician correct the result?

Treat transcription as one stage in an editable pipeline, and the product becomes much more honest—and much more useful.

Building a Browser MIDI Editing Workflow After Audio Conversion

AI Tool Research Lab — Sun, 02 Aug 2026 15:06:24 +0000

An audio-to-MIDI model rarely produces a finished arrangement. The practical output is a draft: notes may be too short, duplicated, shifted by an octave, assigned to the wrong instrument, or split into tracks that still need cleanup.

That makes the editor—not just the converter—part of the workflow.

1. Preserve the raw result

Download the original .mid file and keep it unchanged. Make an editable copy before deleting notes or changing tempo. This gives you a baseline when an edit makes the result worse and preserves evidence for comparing conversion methods.

2. Import and inspect structure

Open the MIDI in a piano-roll editor and check:

tempo and time signature;
track count and instrument assignments;
the lowest and highest detected pitches;
whether the first musical event aligns with the intended start;
clusters of very short notes;
overlapping notes that should represent one sustained event.

PureMIDI's online MIDI editor currently supports browser-side MIDI import, a piano-roll view, multiple tracks, instrument selection, mute/solo/visibility controls, note drawing and erasing, velocity editing, undo/redo, playback, and MIDI export. Some score-derived projects can also expose MusicXML or Guitar Pro-related export paths; those capabilities should not be promised for every imported file.

3. Fix global errors first

Correct errors that affect the whole file before editing individual notes:

Align the start time.
Correct tempo if the imported value is wrong.
Transpose octave-shifted material by 12 semitones.
Assign sensible instruments and track names.
Mute or hide tracks while isolating a problem part.

Global corrections make local note errors easier to see.

4. Clean notes in short sections

Work phrase by phrase. Remove obvious false notes, extend notes that end too early, separate accidental overlaps, and listen after each small batch of changes. Velocity should be edited after pitches and timing are stable; otherwise time is spent polishing notes that may later be deleted.

Keyboard shortcuts and undo/redo matter here because transcription cleanup involves many reversible micro-edits. A useful editor should make the comparison between the original phrase and the changed MIDI fast.

5. Keep track decisions explicit

For multi-track files, record why a track was deleted, merged, duplicated, muted, or assigned another instrument. If the result will be used in a DAW, export a clean MIDI version before adding DAW-specific instruments and effects.

6. Export and verify

After exporting:

reopen the new MIDI file;
verify track count, tempo, notes, and instruments;
listen from the beginning and around every edited boundary;
confirm that the exported file—not only the in-memory editor state—contains the changes.

This round-trip check catches export bugs and unsupported metadata before the source project is closed.

A repeatable cleanup checklist

[ ] Raw conversion preserved
[ ] Tempo and time signature checked
[ ] Start offset corrected
[ ] Octave range checked
[ ] Track names and instruments reviewed
[ ] False and duplicate notes removed
[ ] Note lengths corrected
[ ] Velocity reviewed
[ ] Exported MIDI reopened and verified

Production verification

The public, self-owned benchmark MIDI imports successfully and displays one track with 18 notes. The piano-roll screenshot contains no conversion ID or personal filename.

The first production round-trip check failed: changing the imported file from 120 BPM to 110 BPM and exporting preserved 18 notes and one track, but the parsed duration changed from 17.843 seconds to 8.922 seconds. The cause was a 220 PPQ source being exported with a default 480 PPQ header while retaining the original tick values.

The fix was deployed to production in merge commit f62bbe7efe8ea9addbe7508cb21c6471323eedd6. A fresh browser round trip on https://puremidi.com/midi-editor-online imported the frozen benchmark, changed the tempo from 120 BPM to 110 BPM, and exported 220 PPQ, 110.00011 BPM, one track, 18 notes, and a 19.465-second duration. The production round-trip verification now passes.