Temporal leakage and target leakage are different control problems.
One asks whether information was available when a decision was made. The other asks whether outcome knowledge influenced which candidate features were allowed to enter. Treating them as one vague “leakage check” makes both harder to inspect.
The published exclusion-focused manifest records a six-column declaration with one selected feature and five exclusions. It explicitly records dataset_values_read: false and target_values_read: false.
These are wholly synthetic evaluation records. They demonstrate public contracts and expected outputs; neither archive contains executable audit or freeze logic, a commercial license, customer material, private schemas, or private implementation.
Optional sequence
Freeze eligibility first. Audit availability where time enters.
A team may freeze a candidate-feature declaration before target values are read, then separately audit the availability boundary of temporal context used to compute or join those features.
The records stay distinct. A frozen manifest does not establish that upstream values were computed without future knowledge. A temporal PASS does not establish that the candidate list was selected without label knowledge. Each contract must be reviewed on its own terms.
01
Declare roles without valuesTarget, identity, time, candidate, excluded
02
Freeze candidate eligibilityOrdered manifest plus exclusion ledger
03
Declare temporal clocksDecision, event, availability, and period
04
Audit the as-of boundaryAggregate and row-addressable findings
Combined boundary
Two controls still do not prove “no leakage.”
Together or separately, these tools do not prove correct source data, honest role declarations, target-blind upstream computation, complete lineage, absence of hidden proxies, absence of every future-information path, causal validity, statistical validity, compliance, safety, or fitness. They make two narrower decisions explicit and leave the remaining assurance work visible.
Choose the route
Start with the uncertainty you actually need resolved.
If timing is the risk
Evaluate Temporal Boundary Auditor.
Use the guide, synthetic reports, offline pack, and closed-choice fit check before sending a purchase request.
Are temporal leakage and target leakage the same problem?
No. Temporal leakage asks whether context was actually available at a decision time. Target leakage asks whether outcome knowledge influenced which candidate features were allowed to enter. Each requires a separate declared boundary.
Does passing either control prove that a model has no leakage?
No. Each tool evaluates a narrower declared contract. Neither proves source truth, correct operator declarations, complete lineage, absence of every leakage channel, model validity, causality, safety, or fitness.
Do the two products have to be used together?
No. They are separately licensed local tools with independent contracts and outputs. A team may sequence them deliberately, but neither automatically consumes nor validates the other product's records.
Do I need to upload a dataset to evaluate the products?
No. The public evaluation materials are synthetic and downloadable. The licensed tools run locally without runtime network requests; the Feature Freezer accepts values-free schema metadata, while the Temporal Auditor evaluates local CSV or JSON Lines records.