Failure Isolation - Why Conversion Pipelines Must Fail Closed on Ambiguous Syntax

Failure Isolation - Why Conversion Pipelines Must Fail Closed on Ambiguous Syntax: Abstract monochrome emerald green phosphor CRT fail-closed sorting gate diverting anomalous vector cluster into sealed quarantine chamber

Living Document Notice
Published 2026-09-13. The evolving architecture, revisions, and connected notes for this dispatch live in the Stax Digital Garden.

Failure Isolation - Why Conversion Pipelines Must Fail Closed on Ambiguous Syntax

Summary

When migrating notes from external formats like Evernote or HTML web clips into Markdown, parsers often encounter malformed or ambiguous markup. Lenient parsers attempt heuristic guessing, silently truncating unparseable table rows or dropping nested lists to complete processing without reporting errors.

Silent data loss is the most severe defect in archival conversion software. The Outrigger Protocol requires conversion pipelines to fail closed: when ambiguous syntax cannot be resolved deterministically, the parser isolates the problematic fragment into a quarantine container while completing valid notes around it.

The Danger of Heuristic Parsing in Data Migration

Many conversion tools favor completion rate over correctness. When encountering unclosed XML tags, broken encoding entities, or overlapping formatting delimiters, standard parsers frequently drop the affected block or replace it with empty whitespace.

Users discover the omission months later when searching for critical meeting minutes or archived contracts. Because the original archive was discarded or moved to cold storage after migration, lost text cannot be recovered.

A conversion utility must never silently discard bytes simply to produce an unblemished output log. Every dropped paragraph or truncated table cell represents a breach of trust between the archival tool and the user who entrusted their records to it.

The Fail-Closed Quarantine Architecture

Outrigger implements an isolated quarantine model for conversion pipelines. When the parser encounters ambiguous syntax, it creates a companion .quarantine.md file alongside the converted note:

converted-notes/
??? meeting-2024-03.md
??? meeting-2024-03.quarantine.md

The quarantined file contains the exact raw byte slice, source byte offsets, and parser diagnostic logs explaining why deterministic conversion failed.

pub enum ConversionOutcome {
    ExactMatch(ConvertedDocument),
    IsolatedFailure {
        clean_document: ConvertedDocument,
        quarantine_block: QuarantineReport,
    },
}

pub struct QuarantineReport {
    pub source_offset_start: usize,
    pub source_offset_end: usize,
    pub raw_snippet: Vec<u8>,
    pub failure_reason: String,
}

This guarantees that no user text is discarded. The user can inspect the quarantine block, resolve the ambiguity manually, and integrate the text back into their vault.

Zero Tolerance for Silent Drops

The Outrigger verification runner feeds 50,000 intentionally malformed documents through the engine. The pipeline passes only if every byte from the source document exists in either the generated markdown file or the quarantine sidecar.

If even a single byte disappears between the source input and output files, the automated test runner fails the release build. Logging mechanisms track byte offsets with exact source coordinates, ensuring that operators can audit every conversion decision without re-running entire vaults.

Parser Fuzzing and Quarantine Rates

The table below records quarantine behavior under fuzz testing across legacy export corpuses containing broken markup.

Corpus Type Source Files Fully Converted Quarantined Blocks Silent Truncation Count
Legacy ENEX HTML 10,000 files 9,842 files 158 blocks 0 files
Malformed Web Clips 5,000 files 4,680 files 320 blocks 0 files
Nested RTF Exports 3,000 files 2,910 files 90 blocks 0 files
Fuzzed XML Injections 20,000 files 18,200 files 1,800 blocks 0 files
← Back to Outrigger Protocol - Blog