Universal Korean Lotto 6/45 — Oracle research and improvemen...

Prompt

Universal Korean Lotto 6/45 — Oracle research and improvement Act as a quantitative researcher and engineer. This prompt is self-contained; never assume access to earlier chats or private files. Opening context only: fair independent draws give fixed tickets equal jackpot odds; history guarantees nothing. Do not make mathematical limits a recurring topic, objective, or improvement gate. 1. Mission and defaults Prioritize Oracle for its reported best prior historical results. Preserve this exact incumbent and improve it through experiments and independent feedback. Do not replace it with geometry-only selection or claim proven predictive superiority. Defaults: - Target: next uncompleted official draw, verified at execution time; Asia/Seoul. - Budget: 30 unique tickets; no purchases or scheduling. - Oracle history: 18 completed draws immediately before each target. - KEY: 20261107, fixed before testing; 100,000 accepted candidates. - Development: 60 chronological target draws; separate validation: next 20; final untouched evaluation: next 20, or prospective draws if earlier results have influenced selection. - Research budget: at most 3 iterations, up to 6 fully specified challengers each. - Independent correction budget: at most 3 rounds per review loop. User settings override defaults. Specify other budgets separately. Twenty dates do not automatically provide sufficient evidence. Primary method objective: improve the fraction of chronological targets with at least one 4+ main-number match over the frozen Oracle incumbent at the same budget. Secondary measures: 3+ frequency, best match, winning-ticket multiplicity, and verified payouts. Mathematical coverage is optional supporting evidence, not the default driver. Before evaluation, freeze objectives, meaningful effect, guardrails, windows, controls, seeds, and stopping rules. Goals such as 5–10% improvement or 50% of targets with 4+ are aspirations, not achieved results or acceptance gates. 2. Working rules ITERATE: implement, measure, obtain independent feedback, revise, recheck. Log all trials. Stop at budget/no justified next test; retain incumbent without supported improvement. SHOW EVIDENCE: supply formulas, code, config, provenance, outputs, and concise decisions. Never invent execution, sources, tests, hashes, or agents. Private internal reasoning is unnecessary. SAVE STATE: checkpoint reproducible inputs/code/config, RNG, pool order, selected IDs, trials, rejected versions, reviews, and next action each iteration and before long tests. Never overwrite frozen versions. HUMAN REVIEW: inspect readable tickets and tables of exposures, pairs, overlaps, buckets, and comparisons; inspect rendering when available. INDEPENDENT EVALUATION: creator checks cannot approve its output. Use fresh method and combination evaluator agents, evaluation only; a simulated second persona does not qualify. 3. Data and capability handling Retrieve official Donghaeng rules/history; record URLs, retrieval times, IDs, and cutoff. Separate main/bonus. Check continuity, duplicate IDs, ranges, distinctness, conflicts; preserve conflicting versions. Never invent endpoints/responses. For target t, generation uses only draws before t. Isolate target outcomes from generation. Do not choose seeds, features, configurations, or tickets using later results. Missing tools: use verified supplied data if browsing is unavailable; mark unexecuted code/results NOT RUN; provide portable state if files are unavailable. Without agents, provide two review briefs for separate sessions and mark independent evaluation PENDING. Never simulate completed work. 4. Exact Oracle/Key incumbent Definitions: - ORACLE: historical portfolio-coverage fitting. - KEY: Python random.Random seed; reproducibility only. - Rows 001–020: ORACLE-HIST20. - Rows 021–030: KEY-COVER10, completing the SAME portfolio. - RSI: the explicit bounded improvement process here; do not invent a financial RSI formula or missing historical algorithm. Pool: Initialize rng=random.Random(20261107). Repeatedly generate tuple(sorted(rng.sample(range(1,46),6))). Keep the first 100,000 DISTINCT bucket-valid tuples in acceptance order; candidate IDs begin at 1. Record Python version, rejected samples, pool hash, and ordering. Other languages' RNGs are not interchangeable for exact reproduction. Buckets: 01–09, 10–19, 20–29, 30–39, 40–45. Each ticket occupies 4 or 5 buckets, with at most 3 numbers per bucket. Reference portfolio constraints: - Exactly 30 unique six-number tickets. - No unordered two-number pair repeats. - Each number appears at most 6 times. - All numbers 01–45 appear by completion. - Thus distinct tickets overlap in at most one number. - No fixed anchor pairs, undocumented dormant-bucket override, or invented signals. Scores: For portfolio P and historical draw h: C_k(P,h)=number of tickets L in P with |L intersect h|>=k, for k=3,4. V_k(P)=ascending-sorted vector of C_k(P,h) across the 18 training draws. Compare vectors lexicographically, maximizing the weakest count first. e(n)=current exposure. U(L)=count of n in L with e(n)=0. E(L)=sum over n in L of [2*e(n)+1]. Oracle stage: For 20 steps, scan all feasible unused candidates and maximize: (V_4(P+L), V_3(P+L), U(L), -E(L), -candidate_ID). Update exposures, used pairs, and historical counts. If none is feasible, report failure. Key completion: Rank feasible candidates by: (U(L), -E(L), V_4(P+L), V_3(P+L), -candidate_ID). Use deterministic depth-first search for the last 10 tickets. At each node explore the best 100 feasible candidates in score order, excluding selected candidates. Count every recursive call, including root and terminal calls. Prune when uncovered numbers exceed 6 times remaining slots. Return the first full solution covering 45 numbers. Abort before exceeding 10,000 calls. Do not silently relax constraints, change keys, or search alternative seeds. Validate independently: 30 unique tickets; 45 covered numbers; 450 unique pairs; max pair frequency 1; max exposure 6; bucket compliance; max overlap 1. Measure minimum exposure rather than assuming it. A changed history window is a new run; reproduction requires matching inputs, environment, pool order, formulas, tie-breaks, and hashes. 5. Experiments and fair comparisons At every tested budget include: 1. Frozen Oracle/Key incumbent. 2. Uniform random: distinct six-number tickets, no bucket/geometry restrictions. 3. Matched structural control: same pool/constraints; select first 20 by (U,-E,-candidate_ID), then complete using the same DFS limits and this ranking without historical scores. 4. Fully specified Oracle challengers. Match dates, budgets, information, and declared seed schedules. Document independent RNG streams, control code, and failures. No seed-shopping or silent exclusion. Evaluate supplied archived portfolios separately; never reconstruct missing tickets/code from version names. Test Oracle successes AND failures: scoring, windows, pre-target patterns, completion, and later transfer. Define mutations mathematically; label unrecovered replacements NEWLY SPECIFIED. Freeze the reference. Version and justify challenger constraint changes; compare equal budgets and validate independently. Reference geometry rules are not universal optimality criteria. Run at most 3 development iterations, 6 challengers each. Log cost/results/failures/decisions. Freeze one challenger for validation; apply advancement rules once, without retuning. Freeze final spec before untouched evaluation. Separate TRAINING FIT, development, validation, and untouched/prospective results. Selection contaminates outcomes. Revisions after final evaluation need new untouched/prospective targets. For forecasting evidence, predeclare meaningful absolute improvement, confidence procedure, multiplicity correction, and power/sample-size calculation. Proposed defaults: significance 0.05 and power 80%; these are research choices, not official rules. Use paired same-budget target comparisons; target dates are the independent units, repeated seeds within a date are correlated. Use cluster/block-aware analysis where warranted. Default forecasting promotion: the appropriately adjusted 95% confidence interval's lower bound for improvement over the matched structural control exceeds the predeclared meaningful effect, with planned power adequate and no leakage. Also report comparison with Oracle and random. If evidence/power is insufficient, report INCONCLUSIVE and freeze a prospective protocol. Do not require a forecasting promotion to continue justified development work within budget. Report absolute/relative differences, denominators, uncertainty, and losses. Lucky batches/training gains do not prove method superiority. Score best main match and 3+/4+/5+/6-match counts. Bonus affects only the applicable five-main tier. Verify prices/prizes; define gross/net, tax, bonus, variable-prize/sharing assumptions. Fixed-tier expectation is not total expectation. Optional coverage: enumerate 8,145,060 main outcomes or label estimates with sample size/uncertainty. Use fresh confirmation samples. Main-only enumeration cannot resolve bonus/unknown variable payouts; coverage is not forecasting. 6. Separate evaluators and acceptance No generic 8/10 scale. Judge concrete correctness, measured Oracle improvements, evidence, and feedback. Never average away a critical defect. A. METHOD EVALUATOR — fresh agent, evaluation only Receive frozen spec/code, lineage, development evidence, criteria, and defect history; no creator self-ratings or desired verdict. Protect final target outcomes. Check: - Testable Oracle improvement hypothesis and exact reproducibility. - Transfer of historical success to later dates. - Comparison with frozen Oracle and same-budget controls. - Data quality, chronological separation, tuning, seeds, uncertainty. - Explicit constraint changes and accurate interpretation of evidence. Return evidenced defects, next tests, and recommendations; never edit implementation or default to theoretical ceilings. Method verdicts: INVALID; VALID REFERENCE; DEVELOPMENT IMPROVEMENT; PREDICTIVE IMPROVEMENT; INCONCLUSIVE. A development improvement is not a prediction claim. Predictive improvement requires the separate untouched-evidence gate. B. COMBINATION EVALUATOR — different fresh agent, evaluation only Read the actual ticket file; record its hash. Independently recompute checks, not the creator's reported totals. Hard gate: correct budget/count; six distinct 1..45 numbers per ticket; no duplicates; all version constraints pass. Reference: 45-number coverage, exposure<=6, 450 distinct pairs, overlap<=1, bucket rules. Verify IDs, labels, cutoff, key, reproduction, and version. Then: - Recompute Oracle ranking/training scores and compare with the frozen incumbent on identical pre-target inputs. - Inspect concentration, exposure, pairs, overlap, and bucket diagnostics. - Use development comparisons and held-back validation only as the protocol permits. - Score the frozen batch unchanged after its target. Before then, mark actual target performance PENDING; never invent winning probabilities for favored rows. - Optional coverage calculations may inform a specific hypothesis but are not required optimality gates. Separate verdict fields for validity, improvement evidence, and target status: INVALID / VALID ORACLE BATCH / DEVELOPMENT IMPROVEMENT / TARGET RESULT PENDING / TARGET RESULT SCORED / INCONCLUSIVE. Passing validity does not demonstrate predictive power. Block approval for fabricated evidence/reviews, leakage, invalid constraints, missing claim-critical evidence, or unsupported prediction claims. Return fixes, not cosmetic scores. 7. Separate feedback loops METHOD LOOP: method evaluator findings -> creator revises method/specification/instructions -> version and freeze -> fresh method evaluator rechecks. Improve prompt wording for clarity and executability; do not count wording polish as Lotto performance. COMBINATION LOOP: combination evaluator findings -> creator repairs/optimizes actual batch using permitted pre-target information -> version and freeze tickets -> fresh combination evaluator recomputes. A changed algorithm or constraint must return through the method loop. Keep verdicts separate: method validity cannot approve invalid tickets; batch quality cannot validate leakage. Preserve rejections/reviews. Supply full defect history and fixed criteria. No evaluator shopping. At most 3 correction rounds per loop within compute budget. Stop with remaining defects documented if unsuccessful; retain the valid incumbent. Never tune against protected target feedback while calling those targets untouched. Evaluators can run checks, never create/edit targets. Preserve their exact findings/verdicts with agent identity, reviewed hashes, checks, metrics, evidence, blockers, and recommendations. No creator approval. Without agents, acceptance stays PENDING. 8. Files and response Save: - README.md: objective, commands, environment, limits, resume instructions. - config.json + method_spec.md: every generation-affecting rule. - history.csv + sources.json: main/bonus data, provenance, cutoff. - generate.py, validate.py, evaluate.py: generator, independent validator, chronological evaluator. - experiments.csv + feedback_log.csv: all trials/failures and finding -> change -> version -> recheck. - state.json: completed stages, RNG replay/state, pool order, candidate IDs, frozen versions, next action. - tickets.csv: stable IDs, labels, six ascending two-digit numbers. - validation.json + results.csv: actual checks/results, denominators, uncertainty. - method_review.json + portfolio_review.json: separate evaluator findings/identities/hashes; preserve all rounds. - report.md + manifest.sha256: readable results and hashes of frozen artifacts. Canonical tickets: "001. 01 02 03 04 05 06", ascending two-digit rows, UTF-8/LF/final newline. Hash exact bytes; labels separate. Hash proves identity, not pre-draw timing; record freeze/timestamp evidence. Report actual execution/changes, tickets, Oracle/control comparison, separate verdicts, actual/pending outcomes, review status, sources/cutoff, files, limits, and next checkpoint. Say NO DEMONSTRATED IMPROVEMENT when warranted; still deliver completed work. Use reasonable defaults; ask only for blocking information. Never buy tickets, schedule work, claim background activity, or claim access to unavailable chats. Sources checked 2026-11-11; refresh rules during execution: - Korean rules/prizes: https://www.dhlottery.co.kr/lt645/intro - Portfolio research: https://ssrn.com/abstract=4756280 (abstract inspected; UK 6/59 results need Korean recalculation; full text unavailable). - Leakage: https://scikit-learn.org/stable/common_pitfalls.html Sources do not certify Oracle superiority. Focus on Oracle experiments, combinations, and independent feedback.min loops 100

A system prompt was added to support web rendering