Prepared kinds, Signal status, and readiness

Use the owning status, not a friendly name

Prepared Data and Signals participate in several different status systems:

• Prepared storage state answers whether exact derived payload is usable now;
• Prepared requirement state answers whether a consumer can reuse or build what it needs;
• Signal Library state answers whether the declaration/source is installed;
• Signal readiness answers whether declared inputs and Instrument context can bind in this workspace;
• Strategy Signal-reference state answers whether one exact signal_id:version:column remains structurally and materially compatible; and
• Study readiness answers whether the selected Dataset, window, parameters, topology, fidelity, runtime, and evidence request can execute.

Never collapse those into one Ready badge.

Prepared kind registry

Planned independent L1 Quote Replay

The intended L1 Quote Replay is a separate ordered best-bid/ask resource for Quote fidelity, with state anchors, resets, gaps, scope and trade-to-previously- knowable-state lookup. It can come from a compatible quote source or a certified level-0 projection from Depth.

It is not a current public Prepared kind in the capability registry. The reviewed build still attaches L1 context to some Tick artifacts and lacks the final independent L1 workflow. Treat it as planned/internal until its identity, build, lifecycle, runtime handoff and real-source fixtures pass.

Fidelity-to-Prepared requirements

The effective data floor is the maximum of the selected fidelity, Strategy execution floor, and every Signal requirement. A Bar Study containing an L1 Signal still needs L1. Missing higher-fidelity data never triggers an unrecorded downgrade.

Prepared storage states

State alone is insufficient. Available with the wrong coverage, Dataset, schema, config, alignment, fidelity, build route, data-view checksum, or source role is not compatible.

Prepared requirement-plan states

The consumer-generated requirement plan classifies each exact need:

Requirement-plan v2 is the executable authority. The Prepared inventory is a reader and lifecycle surface; creating a folder or cache row manually cannot satisfy a Study.

Prepared identity and reuse fields

A compatible Prepared object binds:

• kind and schema version;
• source Dataset and every parent Prepared ID;
• exact source role and Instrument/data-view identity;
• semantic configuration and config hash;
• coverage, sessions/alignment and required state anchors;
• build route, implementation and parity/certification evidence;
• partition and auxiliary checksums;
• availability/quality and retention state; and
• dependency/consumer claims.

Friendly Context, recency, local path, or matching columns are not identity.

Retention and lifecycle vocabulary

Signal Outputs do not expose manual Rebuild because their exact Signal, evaluator, parameters, parents, alignment, schema and state binding must be regenerated by a consumer/owned output workflow.

Signal declaration: required input sources

The declared dtype must match. Boolean, integer, float, enum and fixed-width shapes are not interchangeable. Similar labels do not count.

Signal Instrument and temporal requirements

A Signal can require non-column context:

• timezone;
• Tick Size/price increment;
• Point Value/contract economics; and
• Session Calendar.

These come from the exact Dataset/Instrument version. Do not enter ad hoc values inside the Signal to compensate for broken data lineage.

Maximum Signal History is derived from structural temporal access and current resolved parameters:

• no prior rows/bars;
• a finite lookback;
• session-reset history; or
• carried/unbounded state under an explicit state contract.

It includes transitive parent history and alignment. It never grants future rows. Secondary-source alignment uses a backward as-of lookup over eligible closed data with finite tolerance and explicit session-boundary policy; it cannot pull a later value backward or cross a forbidden session.

Signal Library and readiness states

Keep installation separate from data readiness.

The current Signal inspector does not yet render the complete backend readiness projection. Strategy/Study validation remains the operator-visible source of final queueability until status, per-input candidates, unresolved inputs, resolved context, findings and plugin issues are exposed.

Signal implementation and streaming labels

Native is not a certification synonym. Python stream.update() is reference behavior, not a Live fallback.

Strategy Signal-reference status

After a Signal is bound into a Strategy, the exact structured reference has its own lifecycle:

Not built is a data-readiness condition. Missing, stale, ambiguous, missing-column and dtype-mismatch states are structural blockers.

Signal Output identity

signal_output_v3 identity binds:

• exact Signal ID and semantic revision/version;
• implementation/evaluator identity and provenance;
• resolved parameter vector/hash;
• exact primary, secondary and parent Signal Prepared inputs;
• Dataset/data-view, Instrument and session context;
• alignment, warm-up and temporal-state policy;
• output column IDs, dtypes, roles and schema;
• effective coverage and partition checksums; and
• build Job and app/runtime revision.

Changing any semantic field requires a different output. A current-looking column name cannot make old rows compatible.

Readiness decision order

Use this order to avoid circular repairs:

1. confirm exact Signal ID/version/source and declaration validity;
2. review input refs, dtypes, parameters, Instrument context, temporal access and output schema;
3. resolve parent Signal versions and dependency cycles;
4. choose the exact Dataset/source roles and window in the consuming Strategy Study;
5. let the requirement plan find reusable/buildable Prepared parents;
6. resolve missing, ambiguous, stale, partial or capability-blocked layers;
7. verify implementation, compile/evaluator and target certification;
8. Estimate again after every material edit; and
9. after completion, compare requested/effective fidelity and exact Prepared/ Signal Output lineage in the Result.

General Signal Ready does not override a Study's exact window, parameters, fidelity, evaluator, execution model, or evidence blocker.

Technical readiness resolution

exact Signal declaration
  -> expand transitive inputs and temporal/context requirements
  -> resolve exact Dataset and Prepared source candidates
  -> reject missing/stale/ambiguous/incompatible references
  -> derive build/reuse graph and Signal Output identity
  -> validate implementation/evaluator/certification for the Study cell
  -> queue dependency-first durable builds once per exact identity
  -> execute Strategy candidates against the resolved outputs

The backend readiness projection preserves required_inputs, per-input resolutions, eligible candidates, unresolved inputs, resolved context, typed findings and plugin issues separately. load_error wins when discovery issues exist; otherwise unresolved input/findings produce needs_data; only the clean case produces ready. That projection does not select a final consumer binding or grant queue authority.

Next

Use Prepared Data: Build, Reuse, and Retention for lifecycle controls, Read Inputs, Parameters, Outputs, and Readiness for Signal inspection, and Build and Manage Signal Outputs for the currently gated explicit-output workflow.