feat: sync astrology provenance gates

This commit is contained in:
732642856
2026-07-19 08:59:33 +08:00
parent 5298b49a89
commit 82e7b0a95a
12 changed files with 623 additions and 1 deletions
@@ -0,0 +1,47 @@
# Real-case timing optimization audit — 2026-07-19
## Current verified layer
Positive-event replay is healthy:
| Manifest | Cases | Ready | Boundary |
|---|---:|---:|---|
| `references/real_case_calibration/replay_manifest.json` | 10 | 10 | known positive events only |
| `references/real_case_calibration/replay_manifest_holdout_v2.json` | 10 | 10 | blind positive holdout; not specificity proof |
| `references/real_case_calibration/replay_manifest_probe3_v2.json` | 3 | 3 | probe batch only |
This verifies technical recall around known dated events. It does not verify day/month predictive specificity.
## Current blocked layer
Day-level negative holdout remains empty:
- `references/real_case_calibration/day_level_holdout_v3_preregistration.json`
- `annotation_count = 0`
- `negative_count = 0`
- `positive_count = 0`
- `production_tuning_allowed = false`
- `status = awaiting_independent_labels`
Existing 40 control dates remain diagnostic only because they were already observed before preregistration and are not independent human-reviewed labels.
Pilot source queue exists at `references/real_case_calibration/day_level_holdout_v3_pilot_source_queue_2026_07_19.json`.
Boundary: the queue contains public-source candidates for Steve Jobs, Barack Obama, and Albert Einstein. It is not a holdout manifest and must not be used for timing evaluation until independent adjudication converts rows into frozen annotations.
## Optimization needed
1. Collect independent human-labeled non-event intervals for the same subjects/domains.
2. Freeze labels before scoring.
3. Run candidate day/month ranking over positive and negative windows together.
4. Promote timing claims only if positive windows rank above negative windows under frozen rules.
Until then, precise day/month output must stay:
- `timing_precision = candidate_day_window`
- `claim_status = exploratory_unvalidated`
- `production_tuning_allowed = false`
Allowed UX: ranked candidate windows w/ evidence and confidence caps.
Forbidden UX: packaging candidate dates as verified event promises.
@@ -0,0 +1,48 @@
# Shadbala / AV component provenance report — 2026-07-19
Source registry: `references/oracle/shadbala_av_component_provenance_registry_2026_07_19.json`
Status: `classified_unresolved`
Truth policy: `method_variant_not_majority_vote`
Production tuning: `false`
## Component families
| Category | Rows | Component family | Allowed claim |
|---|---:|---|---|
| `shadbala_formula_variant` | 35 | Shadbala six-force components | `component_method_variant` |
| `derived_total_from_component_variants` | 7 | Shadbala total | `derived_total_blocked_until_components_close` |
| `ashtakavarga_table_or_contributor_variant` | 8 | Ashtakavarga tables | `table_variant` |
| `endpoint_or_varga_semantics` | 10 | Varga endpoint semantics | `current_target_observation_only` |
## Unit / source obligations
- Sthana, Dig, Kala, Chesta, Naisargika, and Drik Bala each require formula source, unit, cap/floor, and worked example.
- Total Rupa/Virupa cannot be arbitrated until component units close.
- Ashtakavarga BAV/SAV requires contributor table, shodhana state, Lagna inclusion, and row/column schema.
- VedAstro varga endpoint rows require explicit endpoint/method semantics before truth arbitration.
## Current claim boundary
Allowed:
- current target observations;
- named method variants;
- component-level unresolved status;
- user-safe confidence caps.
Forbidden:
- global Shadbala/AV truth;
- production tuning;
- majority-vote truth;
- copying raw research debt into runtime.
## Next source-evidence queue
1. Map 35 Shadbala component rows to `sthana/dig/kala/chesta/naisargika/drik`.
2. Attach VP Jain / Xalen / jyotishganit / PyJHora observation source per component.
3. Mark each component as `source_explicit`, `method_variant`, or `insufficient_evidence`.
4. Recompute totals only after component status closes.