/**
 * Conformance, and nothing that reading bytes depends on.
 *
 * Layer 7, published as `edfcore/validate`. The split is one line: does the check affect BYTE
 * OFFSETS? If it does, it is core and always on, because correctness is the product and cannot be
 * an optional install. If it only tells you the file is impolite, it lives here — a full-file
 * conformance sweep has no business on the open path.
 *
 * Everything in this module is therefore a re-check: nothing it reports changes how a single byte
 * is interpreted, and a caller who never imports it reads exactly the same samples. Some codes
 * overlap with ones the parser already emits (`RECORD_SIZE_ABOVE_RECOMMENDED`,
 * `PATIENT_ID_NONCONFORMANT`); that is deliberate, so a validation report stands on its own
 * instead of only making sense next to `header.diagnostics`.
 *
 * Four codes here are not in the core vocabulary — `LABEL_CONVENTION_NONCONFORMANT`,
 * `PREFILTERING_NONCONFORMANT`, `TRANSDUCER_TYPE_BLANK` and `DATE_IMPLAUSIBLE`. `EdfDiagnosticCode`
 * is an open union for exactly this: they are recommendations from EDF+ additional specification
 * 9, they can never be fatal, and a consumer's `switch` keeps its `default` branch.
 *
 * Four HERE. `inspect.ts` emits two more of its own, and the six together are listed in
 * `tests/integration/open-union-codes.test.ts` — which is what stops a seventh appearing by
 * typo, since an unregistered code takes `dispositionOf`'s `?? 'warning'` and looks deliberate.
 */
import type { EdfDiagnostic, EdfHeader, EdfRecording, ValidateOptions, ValidationReport } from './types.js';
export { formatValidationReport } from './format-report.js';
/**
 * Every shape this subpath's own signatures mention, re-exported from where it is declared.
 *
 * They live in `types.ts` with everything else — one file holds every public data shape — but a
 * consumer of `edfcore/validate` must be able to name a `ValidationReport` without reaching into
 * the universal entry for it.
 *
 * That has to include the types the signatures REFER to, not only the ones they produce.
 * `validateHeader` takes an `EdfHeader` and returns `EdfDiagnostic[]`, and
 * `FormatReportOptions.header` is an `EdfHeader` — so a consumer who imported only this subpath
 * could call all three functions and still not name the type of anything they passed or received.
 * `tests/types/validate-entry.test-d.ts` pins the set.
 */
export type { EdfDiagnostic, EdfDiagnosticCode, EdfHeader, EdfRecordIndex, EdfRecording, EdfSeverity, EdfSignal, FormatReportOptions, ObservedSignalStats, RecordRange, ValidateOptions, ValidationReport, } from './types.js';
/**
 * Header conformance, as a standalone list.
 *
 * Pure, synchronous and independent of `header.diagnostics`: none of these checks affects a byte
 * offset, so none of them is on the read path, and running them twice costs nothing.
 */
export declare function validateHeader(header: EdfHeader): readonly EdfDiagnostic[];
/**
 * The full conformance sweep.
 *
 * What it costs is stated rather than hidden: `recordsScanned` and `bytesRead` are what actually
 * happened, so a report claiming a file is clean also says how much of it was looked at. A sweep
 * with `scanSamples: false` over a file whose onsets are already known — a complete
 * `options.index`, or a plain EDF whose onsets are arithmetic — reads nothing at all and says so.
 *
 * `diagnostics` gathers everything known about the recording in one array: what the header parse
 * found, what `validateHeader` re-checks, what the timeline probes saw, and what the traversal
 * decoded. Duplicates between them are left in — deduplicating would silently drop the second of
 * two genuinely different occurrences of the same code.
 *
 * A non-monotonic timeline still THROWS, here as everywhere: it is always fatal, because no
 * answer derived from those onsets would mean anything.
 */
export declare function validateRecording(recording: EdfRecording, options?: ValidateOptions): Promise<ValidationReport>;
//# sourceMappingURL=validate.d.ts.map