Open conditions posterior P(requirement met) · bar = 90% credible interval · red line = requirement
What the campaign is still uncertain about. Weighted by the SDA priority of the requirement each condition demonstrates.
Planner queue — next most resource-effective test ranked by expected information gain per $ · feasible with selected assets
Every candidate test event, priced. The top entry is the recommendation; struck-through entries fall below the truncation threshold and are not worth running.
Test event & resource ledger consumed vs. allocated · notional allocations
Knowledge against spend campaign · baseline sequence dashed
Decision log every recommendation, disposition and result — exportable
Critical Test Conditions requirement → condition → measurement events · closure at P ≥ 0.90
Fourteen conditions decomposed from the requirements under test. Each carries its own posterior; a condition closes when confidence that its requirement is met (or not met) reaches the closure threshold. Click a row for its measurement events and the events that move it.
Test event catalog candidate test actions · venue · conditions informed · fidelity · cost
The feasible test space the planner searches. Fidelity is how much an observation in that venue is believed relative to a live event with full truth. Cost is priced from the resource model in step 01 › Prior & cost model; dollar rates are notional placeholders.
Asset selection what this campaign may draw on · unchecked assets make their events infeasible
From the campaign asset catalog (76 assets, 9 categories). The default selection is the Phase II digital/emulator set plus the live assets needed to price live events against digital ones; deselecting an asset removes every event that needs it from the queue.
Asset priorities scarcity multiplies cost · drives which venue the planner prefers
Scarce assets are what a test director protects. Raising a multiplier makes every event that consumes that asset more expensive in the ranking without changing its notional dollar rate.
Asset utilization events run that used each asset
Mission thread — where each condition sits mission thread as tested · launch → warning release · stops short of fire control
The mission is context, not the product. It tells the planner which requirements matter most and where on the thread each condition lives; SCi-Fi reports confidence against these requirements and optimizes the campaign that builds it.
Requirements under test — priority weights SDA's dials · reweight the utility function live
Mission KPPs (M) and system KPPs (S). Weight 1.0 is neutral; 0 removes a requirement from the campaign; 2.0 doubles the information credit for closing its conditions. Thresholds are SDA's to set.
Test scenario definition the setting the planner reasons over · data, not code
Defines the test scenario, not an operational mission: test-article configuration, stimulus set, environment and degradation. Changing it changes which conditions are exercised and the cost of live events.
Four T&E demonstration scenarios each demonstrates the planner doing what a static test matrix cannot
Guided runs on the simulated campaign. Each step is narrated and requires the test-authority approval gate, exactly as a real campaign would. Reset the campaign between scenarios for a clean comparison.
Forecast model control the analyst's modeling choices, visible and traceable
Which prior and likelihood models forecast test outcomes, and how well the forecasts have matched what tests observed. Miscalibration alarms here before it misleads the queue.
Resource cost model notional rates · SDA to set (data request 5)
The denominator of Cost-to-Knowledge. Every event's price is its resource consumption times these rates times any scarcity multiplier. Edit a rate and the queue re-prices.
Variable dictionary every quantity on this console · source · contract trace · refresh · classification estimate
Campaign KPPs status by symbol and word — never color alone
Conditions open · met · not met
Assets that work best robustness · top five for the open conditions
M&S backend federates that will execute the next event
Test geometry — next event 3D globe tool for the full view
Resource posture scarce quotas first
Test geometry assets, coverage and stimulus for the selected test event · not an operational picture · no live entities
What the planner is about to spend: which vehicles and planes are exercised, where the stimulus is, which ground entry points and ranges are booked, and where crosslinks carry the data. Drag to rotate, scrub time to move the constellation.
Event geometry
Layer stack the console is Layer 4; everything below executes what it approves
Federation — models and emulator status · version · what each feeds
Run control executes the approved event through the pipeline · test configuration is data, not code
Standards binding and transport fidelity what the federation speaks · monitored, not operated
Open API — same numbers as the tiles REST/JSON over the containerized stack · PWSA schema-conformant models
Export — updated campaign plan from the live state structure of the T&E Campaign Plan v1.0 · rev-stamped on export
Generates the campaign plan document with the console's current state written into it: requirement weights, condition posteriors and status, the event catalog with runs and dispositions, selected assets with robustness, the approved sequence and remaining queue, calibration, cost rates and the campaign KPP report. The decision log becomes an appendix.
Press Generate to build the document from the current campaign state.
The SCi-Fi — integrated master test plan one hierarchy: objective → core KPPs → conditions → test events and their scenarios → assets · optimize, then re-optimize when data arrives
Everything the campaign will do, in the order a test director reads it. Each level is live: weights re-rank the queue, scenarios change what an event exercises, and new data re-optimizes the sequence. The Export tool writes this hierarchy out as the plan document.