How to Review Kai's MARC Repair Suggestions
Learn how to review Kai's MARC repair suggestions in MARCReady before exporting records for Koha import.
How to Review Kai’s MARC Repair Suggestions
Kai is the AI layer in MARCReady that handles field mapping for structured sources (CSV, TSV, Excel, JSON) and surfaces complex repair suggestions for MARC records.
This article explains what Kai does, how its suggestions appear in the review interface, and how to evaluate them before exporting repaired records.
What Kai does
Kai works in two modes:
For structured non-MARC sources (CSV, TSV, Excel, JSON): Kai analyses column headers or JSON field names and proposes a mapping to MARC21 fields, indicators, and subfields. You review the full mapping before any records are processed.
For MARC sources: Kai reviews records for complex or ambiguous issues that cannot be resolved by the rule engine alone. It suggests per-field repairs and assigns a confidence level (high, medium, or low) to each suggestion.
Kai processes records in batch — it is not a conversational assistant. Suggestions appear in the review interface as a field-by-field repair log.
Note: MARCReady also runs a separate deterministic rule engine that applies unambiguous fixes automatically (indicator correction, ISBN-10 to ISBN-13 conversion, empty subfield removal, 260 to 264 conversion, 336/337/338 generation, and more). These are not Kai suggestions — they are applied before Kai reviews the record. See What MARCReady Can Fix for the full list.
Start with the summary
After MARCReady processes a file, begin with the summary view.
Look for:
- number of records reviewed;
- number of records with issues;
- types of issues found;
- high-confidence suggestions;
- records flagged for librarian review;
- mapping warnings if the source is CSV, Excel, TSV, or JSON.
The summary helps you decide whether the file is mostly clean or needs deeper review.
Understand confidence levels
Kai assigns a confidence level to each suggestion.
- High confidence usually involves clear structural problems, such as an obvious field assignment from a well-named column, or an unambiguous mapping from a legacy tag.
- Medium confidence suggests a likely fix but one that depends on context.
- Low confidence flags something that needs human attention — the suggestion may be wrong or the correct answer may depend on local policy.
Treat low-confidence suggestions as review prompts, not corrections.
Review field mapping suggestions (for CSV/Excel/TSV/JSON)
Before records are exported from a structured source:
- Review each column-to-MARC mapping.
- Confirm that the title column maps to 245
$a. - Confirm that the author column maps to 100 or 700 appropriately.
- Check that ISBNs go to 020
$a. - Verify publication data mapping.
- Confirm that item columns are identified correctly.
- Check that barcode and branch values are preserved.
Do not accept a mapping only because it looks plausible. Incorrect mappings produce technically valid MARC with the wrong data in the wrong fields.
Review MARC field suggestions
For MARC sources, Kai shows a before/after view for each suggested change.
For each suggestion, ask:
- What changed?
- Why did Kai suggest the change?
- Does the repaired field still match the item?
- Is any local information being removed?
- Would this improve Koha import or display?
- Does the change follow your library’s policy?
Do not accept a suggestion only because it looks tidy.
Pay close attention to local fields
Local fields often contain migration-critical data.
Review fields such as:
- 9XX fields;
- item fields;
- old system IDs;
- branch values;
- item type values;
- barcode data;
- location codes;
- vendor-specific notes.
A local field that looks unusual may be important.
Use a sample export
Before exporting a full catalogue, export a small reviewed sample.
Then:
- Stage it in Koha.
- Review staged records.
- Import into a test environment if possible.
- Check staff display.
- Check OPAC display.
- Search by title, author, ISBN, subject, and barcode.
- Confirm item data.
This test confirms whether the accepted repairs work in Koha.
Keep notes
For larger projects, document:
- which suggestions you accepted;
- which suggestions you rejected;
- mapping changes;
- local field decisions;
- known exceptions;
- Koha staging settings.
This helps keep the migration repeatable.
Related articles
Next Steps
More in Resources & Guides
Was this article helpful?