AddThisFeature

AI Import Error Repair

Propose fixes for rejected import rows and let the user retry only those.

involved AI Safety & Trust

What it adds

A repair view for rows that failed validation, with suggested corrections, approval, and a partial retry.

What your agent is told to do

5
  1. 1

    Find where the importer records rejected rows and their validation errors, and build the repair view on that record. If failures are only logged, persist them first with the original row intact.

  2. 2

    Attempt deterministic repair before the model: date and number formats, boolean spellings, trimmed identifiers, known aliases for enumerated values. Send only the rows those rules cannot fix.

  3. 3

    Group identical failures and propose one rule for the group rather than one suggestion per row. A user approving the same date-format fix four hundred times will approve it without reading.

  4. 4

    Never fabricate a value for a required field the file does not contain. Mark those rows as unrepairable and require the user to supply the data or drop the row.

  5. 5

    Retry only the approved rows against the same import job, keyed so that a row that already imported cannot be written twice. Rows that fail again return to the repair view with the new error, not the old one.

Edge cases it handles

8
  • The original row and the exact validation error must stay visible next to every proposal, so a reviewer can tell a formatting fix from a changed meaning.
  • Deterministic parsing must run before the model for dates, numbers, and identifiers. A model guessing between day-first and month-first ordering will be confidently wrong on the twelve days a month where both parse.
  • A missing required value must never be invented. An identifier, price, or email that the file does not contain has to come from the user, not from a plausible-looking guess.
  • A repair rule approved for a group applies uniformly to that group and only after approval, and the affected row count must be shown before it is applied.
  • Retries must be idempotent against the original job. Rows that succeeded on the first pass must not be re-created when the repaired remainder is submitted.
  • A repaired row that now collides with an existing record must surface as a duplicate decision, not be quietly merged or quietly skipped.
  • Rows may contain personal data. Send only the failing fields and their error, exclude columns irrelevant to the failure, and do not log the payload sent to the provider.
  • When the model is unavailable, times out, or returns structured output the app cannot parse, the deterministic repairs and the manual edit path must still work.

Definition of done

9
  • Rejected rows persist with their original values and validation errors and are visible in a repair view.
  • Deterministic parsing resolves format failures before any model call.
  • Identical failures are grouped into a single reviewable rule with the affected row count shown.
  • No suggestion supplies a value for a required field absent from the source file.
  • Retrying repaired rows cannot duplicate rows that already imported.
  • Rows failing a second time return with their current error rather than the original one.
  • Model unavailability leaves rule-based repair and manual editing intact.
  • The feature matches the existing design system.
  • No existing functionality is broken.

Related features

How it works

  1. 1

    Copy the link

    Grab the Markdown instruction URL for this feature.

  2. 2

    Give it to your AI

    Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.

  3. 3

    It inspects, then implements

    Your agent reads your existing app first, then adds the feature to fit it.

Works with your stack

These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.

Need it tighter than that? Customize the feature and tell it exactly what you're running.