@tangle-network/agent-eval 0.144.11 → 0.144.13

package/dist/pre-registration-CZwSFQS4.d.ts

@@ -0,0 +1,577 @@
+import { a as RunRecord } from "./run-record-CKiihE6f.js";
+import { d as PairedBootstrapResult, u as PairedBootstrapOptions } from "./paired-promotion-decision-CGzg0cI_.js";
+//#region src/statistics/paired-binary.d.ts
+/** A binomial proportion estimate with a confidence interval. */
+interface ProportionInterval {
+  /** Point estimate successes / n (0 when n = 0). */
+  estimate: number;
+  /** Lower bound, clamped to [0, 1]. */
+  lower: number;
+  /** Upper bound, clamped to [0, 1]. */
+  upper: number;
+}
+/**
+ * Wilson score interval for a binomial proportion. Correct at small n and near
+ * 0/1, where the normal (Wald) approximation produces bounds outside [0, 1] and
+ * understates coverage. Use this for any pass-rate / hit-rate / realness-rate
+ * CI — the continuous `confidenceInterval` assumes the wrong distribution for a
+ * proportion. `n = 0 ⇒ {0, 0, 0}`.
+ */
+declare function wilson(successes: number, n: number, confidence?: number): ProportionInterval;
+/**
+ * Are these per-item outcomes binary (every value exactly 0 or 1)?
+ *
+ * The discriminator a promotion gate needs before choosing a paired statistic.
+ * On binary outcomes the paired delta vector lives in {-1, 0, +1} and is
+ * normally dominated by zeros (both arms solve, or both arms miss, most items),
+ * so its MEDIAN is pinned at exactly 0 no matter how large the real shift in
+ * success rate is — and a bootstrap CI on that median collapses to [0, 0].
+ * A gate keying on `ci.low > threshold` is then structurally unable to see
+ * either a gain or a regression. Detect this shape and switch to the
+ * paired-binary estimators ({@link mcnemar}, {@link pairedRiskDifference})
+ * instead of silently answering "no" forever.
+ *
+ * Empty input is NOT binary: there is no evidence of the outcome's shape, and
+ * defaulting an empty vector into the binary branch would pick a statistic on
+ * no data at all.
+ *
+ * NOT the right discriminator for a gate. It recognises the literal {0, 1}
+ * encoding and nothing else, so a pass/fail dimension emitted on 0-100 — which
+ * judges in this codebase do routinely — reads as non-binary, and a single
+ * partial-credit score in an otherwise pass/fail vector flips it to false while
+ * leaving the median just as blind. Gates want {@link pairedBinaryScale} (any
+ * two-point encoding). This predicate remains for callers that specifically
+ * mean "literally 0/1".
+ */
+declare function isBinaryOutcomeVector(values: ArrayLike<number>): boolean;
+/** Result of a McNemar paired-binary significance test. */
+interface McNemarResult {
+  /** Total paired observations. */
+  n: number;
+  /** Discordant pairs (b + c) — the only ones that carry signal. */
+  nDiscordant: number;
+  /** Pairs where treatment succeeded and control failed ("newly correct"). */
+  b: number;
+  /** Pairs where control succeeded and treatment failed ("newly wrong"). */
+  c: number;
+  /** Continuity-corrected chi-square statistic (reference; exact p drives the call). */
+  statistic: number;
+  /** Two-sided p-value. Exact (binomial sign test on discordant pairs). */
+  pValue: number;
+}
+/**
+ * McNemar's test for paired binary outcomes — the correct significance test for
+ * "does treatment change the success rate vs control on the SAME items". Only
+ * discordant pairs (one arm right, the other wrong) carry information; concordant
+ * pairs are uninformative, so a paired t-test / two-proportion z-test on the raw
+ * rates is wrong here. The p-value is exact: under H0 the b "treatment-wins" are
+ * Binomial(b + c, 0.5), so the two-sided p is the doubled binomial tail — correct
+ * at the small discordant counts typical of eval runs (no continuity-corrected
+ * chi-square approximation needed, though it is returned as `statistic` for
+ * reference). Inputs are paired 0/1 (or boolean) arrays, control first to match
+ * the module's (before, after) convention. Throws on unequal lengths.
+ */
+declare function mcnemar(control: ArrayLike<number | boolean>, treatment: ArrayLike<number | boolean>): McNemarResult;
+/** A paired binary effect size (treatment rate − control rate) with a CI. */
+interface RiskDifferenceResult {
+  /** Total paired observations. */
+  n: number;
+  /** Discordant pairs: treatment-win count. */
+  b: number;
+  /** Discordant pairs: control-win count. */
+  c: number;
+  /** Paired risk difference p(treatment) − p(control) = (b − c) / n. */
+  riskDifference: number;
+  /** Lower bound of the CI, clamped to [-1, 1]. */
+  lower: number;
+  /** Upper bound of the CI, clamped to [-1, 1]. */
+  upper: number;
+  /** Confidence level used. */
+  confidence: number;
+}
+/**
+ * Paired risk difference (the effect-size companion to {@link mcnemar}): the
+ * change in success rate p(treatment) − p(control) on matched items, which for
+ * paired binary data equals (b − c) / n. The CI uses the paired variance from
+ * the discordant counts, not the independent-samples formula (which overstates
+ * the interval by ignoring the pairing). Inputs are paired 0/1 (or boolean)
+ * arrays, control first. Throws on unequal lengths.
+ *
+ * REPORTING ONLY — do NOT decide a promotion on this interval. The CI is a Wald
+ * normal approximation, which badly UNDERCOVERS when only a handful of pairs are
+ * discordant: at n = 3 with b = 2, c = 0 it returns [0.133, 1.000], excluding 0,
+ * while McNemar's exact test on the same data gives p = 0.50. A gate keying on
+ * `lower > 0` would promote noise. Use {@link pairedRiskDifferenceExact}, whose
+ * interval is dual to the exact test by construction, for any decision.
+ */
+declare function pairedRiskDifference(control: ArrayLike<number | boolean>, treatment: ArrayLike<number | boolean>, confidence?: number): RiskDifferenceResult;
+/** A paired binary effect size with an EXACT interval and the exact test that
+ *  bounds it — one object so a caller cannot read the estimate without the
+ *  significance it is entitled to. */
+interface ExactRiskDifferenceResult {
+  /** Total paired observations. */
+  n: number;
+  /** Discordant pairs: treatment-win count. */
+  b: number;
+  /** Discordant pairs: control-win count. */
+  c: number;
+  /** Discordant pairs (b + c) — the only ones carrying information. */
+  nDiscordant: number;
+  /** Paired risk difference p(treatment) − p(control) = (b − c) / n. */
+  riskDifference: number;
+  /** Exact conditional CI lower bound. 0 when there are no discordant pairs. */
+  lower: number;
+  /** Exact conditional CI upper bound. 0 when there are no discordant pairs. */
+  upper: number;
+  /** Confidence level used. */
+  confidence: number;
+  /** McNemar's exact two-sided p-value on the same discordant counts. */
+  pValue: number;
+}
+/**
+ * Paired risk difference with the EXACT CONDITIONAL interval — the estimator a
+ * promotion gate may decide on.
+ *
+ * Conditional on the number of discordant pairs m = b + c, the treatment-win
+ * count b is Binomial(m, π) with π = P(treatment wins | discordant), and the
+ * risk difference is an exact reparameterisation: RD = (2π − 1)·m/n. So a
+ * Clopper-Pearson exact interval for π maps straight onto RD. This buys the
+ * property the Wald interval in {@link pairedRiskDifference} does not have:
+ *
+ *   **`lower > 0` ⟺ McNemar's exact test rejects at α = 1 − confidence.**
+ *
+ * Clopper-Pearson excludes π = 0.5 exactly when the two-sided exact binomial
+ * test of π = 0.5 rejects, and that test IS {@link mcnemar}'s p-value — so the
+ * interval and the test can never disagree, and a gate keyed on `lower` cannot
+ * promote what the exact test refuses. The exact p is returned in the same
+ * object so the two are impossible to compute apart.
+ *
+ * The interval is conservative (exact intervals over-cover; conditioning on m
+ * discards the concordant pairs' information about m itself). That is the
+ * correct direction for a promotion gate: it refuses more often, never less.
+ *
+ * With m = 0 there are no discordant pairs and π is not identified: the result
+ * is the degenerate [0, 0] with p = 1. That is NOT evidence of equivalence —
+ * callers must treat a zero-width interval as "cannot decide", not as "no
+ * difference". Inputs are paired 0/1 (or boolean) arrays, control first.
+ * Throws on unequal lengths.
+ */
+declare function pairedRiskDifferenceExact(control: ArrayLike<number | boolean>, treatment: ArrayLike<number | boolean>, confidence?: number): ExactRiskDifferenceResult;
+/** A paired binary effect size with an interval that is valid at a NONZERO
+ *  margin — the estimator a noninferiority decision may be made on. */
+interface ScoreRiskDifferenceResult {
+  /** Total paired observations. */
+  n: number;
+  /** Discordant pairs: treatment-win count. */
+  b: number;
+  /** Discordant pairs: control-win count. */
+  c: number;
+  /** Discordant pairs (b + c). */
+  nDiscordant: number;
+  /** Paired risk difference p(treatment) − p(control) = (b − c) / n. */
+  riskDifference: number;
+  /** Score-interval lower bound on the population risk difference. */
+  lower: number;
+  /** Score-interval upper bound on the population risk difference. */
+  upper: number;
+  /** Confidence level used. */
+  confidence: number;
+}
+/**
+ * Paired risk difference with TANGO'S (1998) SCORE INTERVAL — the estimator a
+ * promotion gate may decide on **at a nonzero margin**.
+ *
+ * {@link pairedRiskDifferenceExact} conditions on the observed discordant count
+ * `m = b + c`, builds a Clopper-Pearson interval for the win share among those
+ * `m` pairs, and multiplies by the observed `m/n`. That is exact for testing
+ * RD = 0 — it is dual to McNemar — but it is NOT a confidence interval for the
+ * population risk difference at a nonzero margin, because the sampling
+ * variability of `m/n` itself is discarded. The gap is not academic: with the
+ * production caller's `pairedDeltaThreshold: -0.05`, a process whose true risk
+ * difference sits exactly on that margin clears a nominal-95 % `lower > margin`
+ * check 24.75 % of the time at n = 40 and 43.95 % at n = 76 (2000 replicates
+ * each) when the conditional interval decides.
+ *
+ * Tango's interval inverts the score test of RD = delta, which estimates the
+ * nuisance loss rate under each hypothesised delta instead of fixing it at the
+ * observed value, so `m` contributes its own uncertainty. It is the method
+ * `ratesci::scorepairci` uses for paired risk-difference noninferiority, and it
+ * is not conditional, so it stays valid as the margin moves away from zero.
+ *
+ * The bounds are found by bisecting `tangoScore(delta) = ±z` — the score is
+ * monotone decreasing in delta, so each crossing is unique. Inputs are paired
+ * 0/1 (or boolean) arrays, control first. Throws on unequal lengths.
+ */
+declare function pairedRiskDifferenceScore(control: ArrayLike<number | boolean>, treatment: ArrayLike<number | boolean>, confidence?: number): ScoreRiskDifferenceResult;
+/**
+ * The common positive level `s` such that EVERY value across both paired arms is
+ * exactly 0 or `s` — i.e. the outcome is pass/fail, whatever encoding it arrived
+ * in. Returns null when the outcomes are not two-point, when the two arms use
+ * different levels, or when no positive value was observed at all (all-zero
+ * arms: the level is not identified, and there is nothing to decide anyway).
+ *
+ * This is the scale-aware successor to {@link isBinaryOutcomeVector}, which only
+ * recognises literal {0, 1}. Judges in this codebase emit dimensions on 0-100 as
+ * well as [0,1] (see `detectScale` in `campaign/gates/statistical-heldout.ts`),
+ * so a pass/fail dimension routinely arrives as {0, 100} and a {0,1}-only test
+ * silently sends it down the median path that cannot see it. Any positive level
+ * is accepted, not just 1 and 100: for a two-point {0, s} outcome the mean paired
+ * delta is exactly s·(b − c)/n, so the binary estimators apply after dividing by
+ * s and rescaling the result back into the caller's native units.
+ *
+ * Non-finite values ⇒ null: an unusable outcome must not be classified as a
+ * clean pass/fail shape.
+ */
+declare function pairedBinaryScale(before: ArrayLike<number>, after: ArrayLike<number>): number | null;
+/**
+ * Unbiased pass@k for code generation (Chen et al. 2021, "Evaluating Large
+ * Language Models Trained on Code"). Given `n` independent samples for one
+ * problem of which `c` pass, the probability that at least one of a random k of
+ * them passes is 1 − C(n−c, k) / C(n, k). Estimating pass@k as "did any of the
+ * first k pass" is biased high at small n; this is the variance-reduced estimator
+ * averaged implicitly over all k-subsets. Average the per-problem values across
+ * the suite for the corpus pass@k. Computed in the numerically stable product
+ * form. Requires 1 ≤ k ≤ n and 0 ≤ c ≤ n.
+ */
+declare function passAtK(n: number, c: number, k: number): number;
+//#endregion
+//#region src/statistics/sequential-eprocess.d.ts
+interface EProcessOptions {
+  /** Type-I error budget. The process decides when wealth ≥ 1/alpha
+   *  (Ville's inequality). Default 0.05. */
+  alpha?: number;
+  /** Truncation bound on the predictable bet λ ∈ [0, maxBet]. Must satisfy
+   *  maxBet < 1/nullMean so every wealth factor stays strictly positive.
+   *  Default 0.5. */
+  maxBet?: number;
+  /** The null boundary m₀ for H0: E[x] ≤ m₀ on x ∈ [0,1]. Default 0.5
+   *  (the paired-delta encoding x = (d+1)/2 maps "no effect" to 1/2).
+   *  A pre-registered minEffect shifts this — see `sequentialPairedGate`. */
+  nullMean?: number;
+}
+interface EProcessStep {
+  /** Current wealth W_n — the e-value against H0 after n observations. */
+  wealth: number;
+  /** Observations consumed so far. */
+  n: number;
+  /** True from the first n where W_n ≥ 1/alpha onward (sticky). */
+  decided: boolean;
+}
+interface EProcessState extends EProcessStep {
+  alpha: number;
+  maxBet: number;
+  nullMean: number;
+  /** The decision boundary 1/alpha. */
+  threshold: number;
+  /** Observation count at the first threshold crossing; undefined until decided. */
+  decidedAtN?: number;
+}
+interface EProcess {
+  /** Consume one observation x ∈ [0,1]. Throws on non-finite / out-of-range
+   *  input — a silent clamp would corrupt the type-I guarantee. */
+  update(x: number): EProcessStep;
+  state(): EProcessState;
+}
+/**
+ * Betting test-martingale for bounded observations — the e-process core of
+ * anytime-valid sequential testing (Waudby-Smith & Ramdas, "Estimating means
+ * of bounded random variables by betting", JRSS-B 2024).
+ *
+ * Observations x_i ∈ [0,1]; H0: E[x] ≤ m₀ (`nullMean`, default 1/2). Wealth
+ *
+ *   W_t = Π_{i≤t} (1 + λ_i (x_i − m₀)),  W_0 = 1
+ *
+ * with the truncated GROW-style plug-in bet computed from PRIOR observations:
+ *
+ *   λ_i = clamp((μ̂_{i−1} − m₀) / (σ̂²_{i−1} + (μ̂_{i−1} − m₀)²), 0, maxBet)
+ *
+ * where μ̂/σ̂² are the shrunk running estimates μ̂_t = (1/2 + Σx_i)/(t+1),
+ * σ̂²_t = (1/4 + Σ(x_i − μ̂_i)²)/(t+1).
+ *
+ * PREDICTABILITY INVARIANT (load-bearing): λ_i is a function of x_1..x_{i−1}
+ * ONLY — it may never see x_i. With λ_i ≥ 0 predictable, each factor has
+ * E[1 + λ_i(x_i − m₀) | past] ≤ 1 under H0, so W is a nonnegative
+ * supermartingale and Ville's inequality gives P(∃t: W_t ≥ 1/α) ≤ α — the
+ * type-I guarantee holds at ANY data-dependent stopping time. λ_1 is always 0
+ * (no prior evidence), so the first observation never moves wealth.
+ *
+ * `decided` latches at the first crossing W_t ≥ 1/α and never un-latches;
+ * wealth keeps updating after the crossing (the e-process remains valid), but
+ * the decision time is the first crossing.
+ */
+declare function eProcess(opts?: EProcessOptions): EProcess;
+//#endregion
+//#region src/paired-arms.d.ts
+/** One arm observation of one work item. Structural on purpose: callers
+ *  project their own record type (e.g. a `RunRecord`) into this shape. */
+interface PairedArmRow {
+  /** Matching key — rows sharing a `pairKey` across both arms form pairs
+   *  (typically the task/scenario/seed identity). */
+  pairKey: string;
+  /** Rep identity within a `pairKey` (e.g. a seed or rep number). Required on
+   *  every row of a `pairKey` that has more than one rep in either arm; reps
+   *  then pair only on exact (`pairKey`, `repKey`) match, never on outcome
+   *  content. Optional when each arm has at most one rep of the item. */
+  repKey?: string;
+  /** Arm label this row was produced under. */
+  arm: string;
+  /** Binary outcome; omit when the comparison has no pass/fail notion. */
+  pass?: boolean;
+  /** Named numeric measurements (score, cost, latency, …). */
+  metrics?: Record<string, number>;
+}
+interface PairArmsOptions {
+  /** Arm treated as the control side of every pair. */
+  baselineArm: string;
+  /** Arm treated as the treatment side of every pair. */
+  treatmentArm: string;
+}
+/** One matched (baseline, treatment) observation of the same work item. */
+interface MatchedPair {
+  pairKey: string;
+  /** 0-based position of this pair within its `pairKey`, ordered by sorted
+   *  `repKey` (always 0 for a single-rep item). The rep identity itself is on
+   *  the rows (`baseline.repKey` / `treatment.repKey`). */
+  repIndex: number;
+  baseline: PairedArmRow;
+  treatment: PairedArmRow;
+}
+interface PairArmsResult {
+  /** Matched pairs, ordered by (`pairKey`, `repIndex`). */
+  pairs: MatchedPair[];
+  /** Baseline rows left without a treatment counterpart — reported, never
+   *  silently dropped. */
+  unpairedBaseline: PairedArmRow[];
+  /** Treatment rows left without a baseline counterpart. */
+  unpairedTreatment: PairedArmRow[];
+}
+/**
+ * Match rows across two arms into (baseline, treatment) pairs by `pairKey`.
+ *
+ * A `pairKey` with at most one row per arm pairs directly, no `repKey`
+ * needed. A `pairKey` with multiple reps in either arm requires `repKey` on
+ * every one of its rows, and reps pair only on exact (`pairKey`, `repKey`)
+ * match — pairing is keyed purely on row identity, never on outcome content
+ * (outcome-keyed matching deflates discordant counts and biases McNemar), and
+ * is therefore independent of input order. Reps whose `repKey` has no
+ * counterpart in the other arm, and items present in only one arm, land in
+ * the unpaired lists — reported, never truncated.
+ *
+ * Fail-loud: throws when either named arm has zero rows (an unknown arm
+ * name would otherwise read as "everything unpaired"), when the two arm
+ * names are equal, when a multi-rep `pairKey` has a row without `repKey`, or
+ * when a (`pairKey`, arm) group repeats a `repKey` (the match would be
+ * ambiguous).
+ */
+declare function pairArms(rows: readonly PairedArmRow[], opts: PairArmsOptions): PairArmsResult;
+/** Paired pass/fail comparison over the pairs where BOTH sides carry `pass`. */
+interface PairedCorrectness {
+  /** Discordant pairs where the treatment passed and the baseline failed. */
+  b10: number;
+  /** Discordant pairs where the baseline passed and the treatment failed. */
+  b01: number;
+  /** Exact McNemar significance over the paired outcomes (`b === b10`, `c === b01`). */
+  mcnemar: McNemarResult;
+  /** Paired effect size: p(treatment) − p(baseline) with a paired-variance CI. */
+  riskDifference: RiskDifferenceResult;
+}
+/** Paired delta summary for one named metric (delta = treatment − baseline). */
+interface PairedMetricDelta {
+  name: string;
+  /** Pairs where BOTH sides carry a finite value for this metric. */
+  n: number;
+  /** Pairs where at least one side does not carry the metric. */
+  nMissing: number;
+  /** Median paired delta, or null when `n === 0`. */
+  medianDelta: number | null;
+  /** Mean paired delta, or null when `n === 0`. */
+  meanDelta: number | null;
+  /** Bootstrap CI on the paired delta (`pairedBootstrap`); null when
+   *  `n === 0` — a zero-width [0, 0] interval on no data would read as a
+   *  measured tight null. */
+  bootstrapCi: PairedBootstrapResult | null;
+  /** Wilcoxon signed-rank test on the paired deltas; null when `n === 0`. */
+  wilcoxon: {
+    w: number;
+    p: number;
+  } | null;
+}
+interface ComparePairedArmsOptions extends PairArmsOptions {
+  /** Metrics to compare. Default: every metric name observed on any matched
+   *  pair, sorted. A name that appears on no pair is still reported (with
+   *  `n = 0`) so a misspelled metric is visible instead of vanishing. */
+  metricNames?: string[];
+  /** Passed through to `pairedBootstrap` — set `seed` for reproducible CIs. */
+  bootstrap?: PairedBootstrapOptions;
+}
+interface PairedArmsComparison {
+  nPairs: number;
+  nUnpairedBaseline: number;
+  nUnpairedTreatment: number;
+  /** null when no matched pair carries `pass` on both sides — a pass/fail
+   *  verdict over rows that never measured pass/fail would be fabricated. */
+  correctness: PairedCorrectness | null;
+  metricDeltas: PairedMetricDelta[];
+}
+/**
+ * Full matched-pair arm comparison: pair via {@link pairArms}, then compose
+ * the paired estimators from `statistics` over the matched pairs.
+ *
+ * Correctness uses only the pairs where both sides carry `pass` (`mcnemar.n`
+ * is that subset's size); each metric uses only the pairs where both sides
+ * carry a finite value for it, with the remainder counted in `nMissing`.
+ * Deltas are treatment − baseline throughout.
+ *
+ * Fail-loud: inherits {@link pairArms}'s unknown-arm throw, and throws on a
+ * non-finite metric value — silently treating corrupt telemetry as "metric
+ * absent" would misreport it as missing coverage.
+ */
+declare function comparePairedArms(rows: readonly PairedArmRow[], opts: ComparePairedArmsOptions): PairedArmsComparison;
+interface MatchedRunRecordPair {
+  pairKey: string;
+  repKey: string;
+  baseline: RunRecord;
+  treatment: RunRecord;
+}
+interface PairRunRecordsResult {
+  pairs: MatchedRunRecordPair[];
+  unpairedBaseline: RunRecord[];
+  unpairedTreatment: RunRecord[];
+}
+/**
+ * Pair two RunRecord arms by the identity of the evaluated work:
+ * `(experimentId, scenarioId, seed)`.
+ *
+ * Falling back to array order, candidate id, or experiment id can compare
+ * different tasks and fabricate lift. Duplicate identities throw.
+ */
+declare function pairRunRecords(baselineRuns: readonly RunRecord[], treatmentRuns: readonly RunRecord[]): PairRunRecordsResult;
+//#endregion
+//#region src/pre-registration.d.ts
+/**
+ * Pre-registered hypotheses — declare what you're testing BEFORE the
+ * run, check it AFTER. Prevents p-hacking, optional stopping, and the
+ * "we ran until it looked good" failure mode.
+ *
+ * Manifest is a plain JSON-friendly object. Sign it with a content hash
+ * + timestamp; the registered record becomes immutable. Post-run,
+ * evaluate the manifest against observed results — the library refuses
+ * to let you re-interpret a different metric as the declared one.
+ */
+interface HypothesisManifest {
+  id: string;
+  /** Human prose — goes into the audit trail. */
+  hypothesis: string;
+  /** Metric the hypothesis claims to move. */
+  metric: string;
+  /** 'increase' = candidate should score higher than baseline; 'decrease' = lower. */
+  direction: 'increase' | 'decrease';
+  /** Minimum effect size to count (same units as the metric). */
+  minEffect: number;
+  /** Alpha threshold. */
+  alpha: number;
+  /** Target statistical power at which sample size was pre-computed. */
+  power: number;
+  /** Declared N per arm before running. */
+  preRegisteredN: number;
+  /** ISO8601 timestamp the manifest was registered. */
+  registeredAt: string;
+  /** Optional identifiers to tie into the trace corpus. */
+  baselineLabel?: string;
+  candidateLabel?: string;
+}
+/**
+ * Identifier for the hashing scheme used to produce `contentHash`.
+ *
+ * `'sha256-content'` — sha256 hex over the canonicalized manifest with
+ * the `contentHash` and `algo` fields stripped. Held as a string union
+ * so future schemes can be added without breaking parsers; SignedManifest
+ * values without `algo` deserialize cleanly because the field is optional.
+ */
+type SignedManifestAlgo = 'sha256-content';
+interface SignedManifest extends HypothesisManifest {
+  /** sha256 hex of canonicalized manifest (everything except contentHash and algo). */
+  contentHash: string;
+  /**
+   * Algorithm string describing how `contentHash` was produced.
+   *
+   * Optional on the type so serialized manifests without it still parse,
+   * but ALWAYS populated by {@link signManifest}. Consumers that want to
+   * enforce a known algorithm should reject manifests where this field
+   * is missing or unrecognized.
+   */
+  algo?: SignedManifestAlgo;
+}
+interface HypothesisResult {
+  manifest: SignedManifest;
+  observedN: number;
+  observedEffect: number;
+  observedPValue: number;
+  /** True iff the observed effect hits the pre-declared direction with
+   *  magnitude ≥ minEffect AND p < alpha. */
+  confirmed: boolean;
+  /** Enumerated reasons the hypothesis was rejected (each a machine-tag). */
+  rejectionReasons: Array<'wrong_direction' | 'effect_too_small' | 'not_significant' | 'undersampled'>;
+  notes?: string;
+}
+/**
+ * Deterministic JSON canonicalization — sort object keys recursively.
+ *
+ * Two semantically-equal objects produce byte-identical canonicalized output;
+ * this is what makes a content-hash stable across encoders, key insertion
+ * orders, and runtime versions. Exported for any consumer that needs the same
+ * canonicalization guarantee outside the manifest-signing path (e.g., signing
+ * an artifact bundle, hashing a dataset version, etc.).
+ */
+declare function canonicalize(v: unknown): unknown;
+/**
+ * SHA-256 hex (full 64 chars) over the canonicalized JSON encoding of `obj`.
+ *
+ * The same primitive `signManifest` and `verifyManifest` are built on, exposed
+ * directly so consumers signing arbitrary structured content (artifact bundles,
+ * production packets, dataset manifests, etc.) don't have to re-derive
+ * canonicalize+sha256 from scratch.
+ *
+ * Stable across:
+ *   - object key insertion order (canonicalization sorts keys recursively)
+ *   - encoder choice (UTF-8 via TextEncoder, fixed)
+ *   - runtime (uses the Web Crypto subtle digest, present in Node ≥18 and browsers)
+ *
+ * Named `hashJson` to disambiguate from `prompt-registry.ts`'s `hashContent`,
+ * which takes a string input and returns a truncated 12-char prompt id.
+ * Use `hashJson` when you mean "canonicalize then hash."
+ *
+ * @example
+ *   const hash = await hashJson({ id: '1', kind: 'spec' })
+ *   // 'a3f1...' (64 hex chars)
+ */
+declare function hashJson<T>(obj: T): Promise<string>;
+/**
+ * Sign a manifest with a SHA-256 content hash.
+ *
+ * The hash covers the canonicalized manifest with the `contentHash`
+ * and `algo` fields stripped; this lets verifiers re-sign the rest and
+ * compare. Returned manifest always carries `algo: 'sha256-content'`
+ * so downstream consumers can identify the scheme; manifests without
+ * `algo` still verify because it is stripped before hashing on both sides.
+ */
+declare function signManifest(m: HypothesisManifest): Promise<SignedManifest>;
+/**
+ * Verify that a signed manifest has not been tampered with.
+ *
+ * Strips `contentHash` and `algo` before re-signing so manifests without
+ * `algo` verify identically to ones that carry it.
+ */
+declare function verifyManifest(m: SignedManifest): Promise<boolean>;
+/**
+ * Evaluate a pre-registered hypothesis against observed results.
+ * Mechanical — no re-interpretation permitted.
+ */
+declare function evaluateHypothesis(manifest: SignedManifest, observed: {
+  n: number;
+  effect: number;
+  pValue: number;
+}): Promise<HypothesisResult>;
+//#endregion
+export { isBinaryOutcomeVector as A, EProcessStep as C, ProportionInterval as D, McNemarResult as E, pairedRiskDifferenceScore as F, passAtK as I, wilson as L, pairedBinaryScale as M, pairedRiskDifference as N, RiskDifferenceResult as O, pairedRiskDifferenceExact as P, EProcessState as S, ExactRiskDifferenceResult as T, comparePairedArms as _, evaluateHypothesis as a, EProcess as b, verifyManifest as c, PairArmsOptions as d, PairArmsResult as f, PairedMetricDelta as g, PairedCorrectness as h, canonicalize as i, mcnemar as j, ScoreRiskDifferenceResult as k, ComparePairedArmsOptions as l, PairedArmsComparison as m, HypothesisResult as n, hashJson as o, PairedArmRow as p, SignedManifest as r, signManifest as s, HypothesisManifest as t, MatchedPair as u, pairArms as v, eProcess as w, EProcessOptions as x, pairRunRecords as y };
+//# sourceMappingURL=pre-registration-CZwSFQS4.d.ts.map

package/dist/pre-registration-CZwSFQS4.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"pre-registration-CZwSFQS4.d.ts","names":[],"sources":["../src/statistics/paired-binary.ts","../src/statistics/sequential-eprocess.ts","../src/paired-arms.ts","../src/pre-registration.ts"],"mappings":";;;;UAgBiB;;EAEf;;EAEA;;EAEA;;;;;;;;;iBAUc,OAAO,mBAAmB,WAAW,sBAAoB;;;;;;;;;;;;;;;;;;;;;;;;;;iBA2CzD,sBAAsB,QAAQ;;UAU7B;;EAEf;;EAEA;;EAEA;;EAEA;;EAEA;;EAEA;;;;;;;;;;;;;;iBAec,QACd,SAAS,6BACT,WAAW,8BACV;;UAmBc;;EAEf;;EAEA;;EAEA;;EAEA;;EAEA;;EAEA;;EAEA;;;;;;;;;;;;;;;;;iBAkBc,qBACd,SAAS,6BACT,WAAW,6BACX,sBACC;;;;UAkCc;;EAEf;;EAEA;;EAEA;;EAEA;;EAEA;;EAEA;;EAEA;;EAEA;;EAEA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;iBA+Bc,0BACd,SAAS,6BACT,WAAW,6BACX,sBACC;;;UAyEc;;EAEf;;EAEA;;EAEA;;EAEA;;EAEA;;EAEA;;EAEA;;EAEA;;;;;;;;;;;;;;;;;;;;;;;;;;;iBA8Dc,0BACd,SAAS,6BACT,WAAW,6BACX,sBACC;;;;;;;;;;;;;;;;;;;;iBA6Ea,kBACd,QAAQ,mBACR,OAAO;;;;;;;;;;;iBA0BO,QAAQ,WAAW,WAAW;;;UCjgB7B;;;EAGf;;;;EAIA;;;;EAIA;;UAGe;;EAEf;;EAEA;;EAEA;;UAGe,sBAAsB;EACrC;EACA;EACA;;EAEA;;EAEA;;UAGe;;;EAGf,OAAO,YAAY;EACnB,SAAS;;;;;;;;;;;;;;;;;;;;;;;;;;;;;iBA8BK,SAAS,OAAM,kBAAuB;;;;;UC/BrC;;;EAGf;;;;;EAKA;;EAEA;;EAEA;;EAEA,UAAU;;UAGK;;EAEf;;EAEA;;;UAIe;EACf;;;;EAIA;EACA,UAAU;EACV,WAAW;;UAGI;;EAEf,OAAO;;;EAGP,kBAAkB;;EAElB,mBAAmB;;;;;;;;;;;;;;;;;;;;iBAqBL,SAAS,eAAe,gBAAgB,MAAM,kBAAkB;;UA8G/D;;EAEf;;EAEA;;EAEA,SAAS;;EAET,gBAAgB;;;UAID;EACf;;EAEA;;EAEA;;EAEA;;EAEA;;;;EAIA,aAAa;;EAEb;IAAY;IAAW;;;UAGR,iCAAiC;;;;EAIhD;;EAEA,YAAY;;UAGG;EACf;EACA;EACA;;;EAGA,aAAa;EACb,cAAc;;;;;;;;;;;;;;;iBAgBA,kBACd,eAAe,gBACf,MAAM,2BACL;UAmEc;EACf;EACA;EACA,UAAU;EACV,WAAW;;UAGI;EACf,OAAO;EACP,kBAAkB;EAClB,mBAAmB;;;;;;;;;iBAeL,eACd,uBAAuB,aACvB,wBAAwB,cACvB;;;;;;;;;;;;;UC1Wc;EACf;;EAEA;;EAEA;;EAEA;;EAEA;;EAEA;;EAEA;;EAEA;;EAEA;;EAEA;EACA;;;;;;;;;;KAWU;UAEK,uBAAuB;;EAEtC;;;;;;;;;EASA,OAAO;;UAGQ;EACf,UAAU;EACV;EACA;EACA;;;EAGA;;EAEA,kBAAkB;EAGlB;;;;;;;;;;;iBAYc,aAAa;;;;;;;;;;;;;;;;;;;;;;iBA8BP,SAAS,GAAG,KAAK,IAAI;;;;;;;;;;iBAkBrB,aAAa,GAAG,qBAAqB,QAAQ;;;;;;;iBAW7C,eAAe,GAAG,iBAAiB;;;;;iBAWnC,mBACpB,UAAU,gBACV;EAAY;EAAW;EAAgB;IACtC,QAAQ"}