Documentation

A spreadsheet contains a customer ID of 00127. Someone imports it. The import reports success, every row lands, and the value in the database is now 127. An integer cast stripped the leading zero, and nothing flagged it because nothing was technically invalid.

MoveProof moves spreadsheet data into an explicit destination contract and then checks, with code that had no part in writing the transformation, whether the values survived. The same architecture currently serves customer migrations and per-joint robot calibration data.

Inspect, plan, review, stage, verify, repair, commit, report. Four of those need a decision from you: approving a plan, resolving a review item, approving a repair, and committing.

Nemotron 3 Super proposes the initial mapping. MoveProof then validates that proposal deterministically. When the validator detects multiple independent concerns, the same bounded context may be selectively escalated to Nemotron 3 Ultra for deeper reasoning. Validated code executes exactly what you approved. An independent verifier determines what actually happened, and you approve anything ambiguous. When field semantics are unclear, External Evidence Check can retrieve advisory public references to help inform that decision without changing verification results or commit eligibility.

The repository ships a deterministic synthetic dataset generator with a fixed seed. It produces files of any size with known hazards planted at known positions, along with a manifest used by the test suite. The application never reads that manifest: every result it shows is computed by executing real checks.

When one migration is finished, start a new migration for the next source file. Related files are not silently merged into a single execution scope. This keeps failures and rollback boundaries explicit.

MoveProof currently exposes two server-defined destination profiles: customers_v1 for customer records and robot_calibration_v1 for per-joint calibration records. The selected profile is stored with the migration, so planning, execution, verification, evidence, export, commit and rollback resolve the same contract.

Robotics row identity is the composite key (robot_id, joint_name). The verifier separately checks that identifier-like values such as 0017 and firmware text such as 3.08 survive the move, while ambiguous dates and decimal conventions require an explicit human decision.

A passed robotics migration verifies those approved data invariants. It does not determine whether a calibration value is physically correct, command a robot, or certify hardware safety.

The deployed robot_calibration_v1workflow has been exercised end to end with the clean, ambiguous and multi-joint robotics fixtures. The clean path remained on Nemotron 3 Super, the ambiguous path exercised deterministic escalation to Nemotron 3 Ultra and explicit human decisions, and the multi-joint path preserved composite (robot_id, joint_name)identity.

Production checks also exercised verified CSV export, evidence generation, commit behavior, fail-closed destination conflicts and rollback. This status is evidence about migration integrity, not a statement that MoveProof validated physical calibration quality or robot safety.

CSV, TSV, XLSX and XLSM, up to the size limit shown in Settings. Encoding and delimiter are detected. Every cell is read as text: no value is coerced to a number or a date during parsing, because a parser that guesses can destroy a leading zero before anybody has approved anything.

A cell containing something like =SUM(A1:A9) is stored exactly as written and never evaluated.

Results come back in four categories that do not overlap. Passed means a check ran and succeeded. Failed means an approved invariant was violated. Review required means a human decision is outstanding. Not verified means the property was never checked.

The fourth category matters most. A property that was not checked is never folded into a passing score, and the evidence report names every one of them.

Commit is blocked while any mandatory check has failed or awaits a decision. That gate lives in the backend and is checked again against stored records at commit time, so it cannot be bypassed by a screen that forgot to disable a button.

A repair never edits the approved plan. It creates a new version with a reviewable diff, and the rerun reads the original uploaded file again. A leading zero destroyed by an integer cast cannot be recovered from the integer, so the repair has to return to the source.

A commit that meets an existing destination row fails closed rather than skipping it quietly. Skipping requires an explicit policy.

After a migration passes verification, MoveProof can export the verified transformed dataset as CSV. The export is generated by the backend from stored verified data rather than reconstructed from browser state, preserving identifier values such as 00127.

Verified CSV is available when a migration is ready to commit and remains available after commit. Failed or unverified migrations cannot be exported as verified data.

CSV contains the verified transformed dataset. JSON, HTML and PDF serve a different purpose: they contain the migration evidence and audit record.

Only a summary of the schema and a small bounded sample of rows, the size of which is shown in Settings, can enter model-assisted reasoning. Full datasets are never sent to the model. Both the routine and escalation passes use the same bounded sampling path rather than sending additional rows to the deeper reasoning model.

Nemotron 3 Super, served through Nebius Token Factory, handles the initial model-assisted planning pass. Its output is treated as untrusted input and validated deterministically against the supported operation allowlist.

The model never emits SQL, shell commands, or executable code. Two deterministic profiles also remain available without live model credentials, keeping the core migration and verification workflow reproducible in local and test environments.

MoveProof does not ask the model whether it needs a more powerful model. The routing decision is made by deterministic validation of the initial Super proposal.

A validator concern is something MoveProof already knows how to detect, such as a mapping that requires explicit acknowledgement or a non-fatal validation issue. If fewer than two concerns are detected, MoveProof keeps the Super proposal. Two or more concerns can trigger a second reasoning pass with Nemotron 3 Ultra when escalation is configured.

The Ultra pass receives the same bounded model context and remains subject to the same parsing, allowlist validation, human approval, and execution gates as the initial proposal. Escalation does not grant the model authority to execute transformations, approve a plan, change a verification result, or commit destination data.

If the escalation model is not configured, MoveProof continues with the validated Super proposal. If an escalation request fails, the Super proposal remains available and the failure is recorded rather than granting additional authority.

Some migration questions cannot be answered from the uploaded data alone. A value such as 00127 may clearly be zero-padded, but the dataset itself may not establish whether that formatting is semantically required by the source system.

External Evidence Check lets a reviewer retrieve public references through Tavily while reviewing an ambiguous mapping. The reviewer chooses from a fixed set of questions, and MoveProof constructs the query on the backend.

Only validated schema and review metadata are sent. Uploaded files, full datasets, sampled rows and raw cell values are not sent to Tavily.

The returned sources are advisory. They cannot approve a plan, modify data, change a verification result, satisfy a mandatory check or bypass the commit gate. The reviewer remains responsible for deciding whether the external evidence is relevant and trustworthy.

External Evidence Check is enabled in the production deployment and has been verified through a real Tavily runtime request.

The original uploaded bytes are stored alongside the parsed rows so a repair has an authoritative source and a checksum can be recomputed later. Robot calibration files can contain operationally sensitive values and are handled under the same private-data boundary as every other uploaded dataset.

Deleting an uncommitted or already rolled-back migration removes its source, plans, runs, staged rows, checks and events. A committed migration cannot be deleted directly. Its committed destination rows must first be removed through an explicit rollback, and the migration itself can only be deleted after that rollback succeeds.

Human approvals recorded in an evidence report are audit entries. They are not cryptographic signatures, and the product does not describe them as such.

The repository README covers setup, testing and deployment in full.

Open the repository