/**
 * The local golden set: query -> relevant document id pairs.
 *
 * CONSTRUCTION RULES (enforced by the harness, not just by good intentions):
 *  1. Every `relevant` id is a repo-relative path that must exist in the
 *     deterministic corpus. Unknown ids are a hard failure, never a silent skip.
 *  2. Queries are written in DIFFERENT vocabulary from the source document —
 *     the wording a person would use months later having forgotten the doc's
 *     own terms. Pairs whose query turns out to be near-verbatim in the target
 *     are removed automatically by `assessTriviality` and reported.
 *  3. Relevance is pinned to LIVE documents: the eval store is rebuilt from the
 *     corpus with exactly one ingest per document, so it contains no superseded
 *     versions at all. Deleting dead rows from the user's store (backlog item 4)
 *     therefore cannot move these numbers.
 *  4. Ambiguous targets are avoided. Where several near-identical documents
 *     could each legitimately answer, either the query is sharpened or all
 *     acceptable documents are listed in `relevant`.
 *
 * @module v1/cli/knowledge/eval/golden-set
 */
export interface GoldenPair {
    id: string;
    query: string;
    /** Repo-relative paths. A hit on ANY counts for hit-rate; recall uses all. */
    relevant: string[];
    /** Free-form grouping for slice reporting. */
    tags?: string[];
}
/**
 * v1 of the set. Authored 2026-07-28 by `benchmark-engineer` against documents
 * read at authoring time. Growing this set is ongoing work; the count is
 * reported honestly by the harness rather than padded with near-duplicates.
 */
export declare const GOLDEN_SET: GoldenPair[];
export type Split = 'dev' | 'test';
/** Share of pairs assigned to the sealed test split. */
export declare const TEST_SHARE = 0.3;
/** Identifies the assignment scheme. Bump this whenever assignment changes:
 *  numbers measured under different schemes are not comparable, and the
 *  regression suite uses this to say so instead of inventing a regression. */
export declare const SPLIT_SCHEME = "hash-threshold-v2";
/**
 * Stratified 70/30 dev/test split, STABLE UNDER GROWTH.
 *
 * The assignment is a pure function of the pair's own id — `pairHash(id) <
 * TEST_SHARE` — so adding pairs never moves an existing pair between splits.
 *
 * The first version ranked pairs within their tag group and took the lowest
 * 30%, which gave an exact 70/30 per tag but was NOT stable: appending one
 * pair to a group re-ranked it and silently reassigned existing pairs. Growing
 * the set would have quietly moved queries out of the sealed half and into the
 * tunable one, which is the seal failing open — and it would have done so with
 * no visible symptom at all.
 *
 * Stratification survives because the hash is uniform and independent of the
 * tag, so each tag group lands near 30% on average rather than exactly. That
 * is the right trade: an approximate stratification that cannot leak beats an
 * exact one that can.
 */
export declare function assignSplits(pairs?: GoldenPair[]): Map<string, Split>;
export declare function pairsForSplit(split: Split | 'all', pairs?: GoldenPair[]): GoldenPair[];
//# sourceMappingURL=golden-set.d.ts.map