How F.10–F.11 Extend This Style (Without Changing Your Identity)

Domains F.4 through F.9 quietly established something powerful: each technical block — guidance, control, estimation, geometry, detectability, and scaling — is not an isolated discipline. Each block produces outputs that become inputs to the next. Each block constrains the others. And if one block is even slightly inconsistent (frame mismatch, timing drift, unrealistic actuator assumptions), it can silently invalidate the logic downstream.

By the time a reader reaches F.9, they have already learned how mission reasoning should be built:

• F.4 gave the plane-targeting truth: “Pitch gets you to orbit; yaw + time get you into the plane.”
• F.5 made hardware real: stability means nothing if actuators saturate.
• F.6 made state knowledge real: filters fail from tuning and dropouts, not from missing equations.
• F.7 introduced event logic: geometry produces crossing intervals, not just sampled booleans.
• F.8 applied operational truth: crossing ≠ detection (illumination + range gates matter).
• F.9 made scaling real: reject cheaply, refine only inside windows, store intervals not samples.

So what remains is not a new topic. What remains is integration. F.10 and F.11 should not introduce a new visual style, a new reasoning style, or a new tone. They should unify what already exists into a single mission-level loop.

F.10 — Integrated Mission Template

Purpose

F.10 combines everything built so far into one coherent, end-to-end mission evaluation loop:

Up to now, these have been explored individually. F.10 shows how they interact in sequence, where each stage constrains and shapes the next. This is where Domain F transitions from “technical modules” to “mission reasoning.”

1) Integrated Mission Scenario

Begin with a mission framing that naturally demands cross-domain reasoning.

This single sentence forces interaction between:

• Plane targeting (F.4) — correct inclination, RAAN, and LTAN drift logic.
• Propagation + geometry (F.7) — when crossings exist in time.
• Detectability gates (F.8) — which crossings are physically usable.
• Scaling mindset (F.9) — how to run this without brute force.

2) System Architecture — What Talks to What

A mission is not a single equation. It is a chain of modules passing shared state forward. Each module consumes and transforms state. Each module depends on upstream correctness.

1. Launch window solver → chooses t0 for target plane/LTAN alignment.
2. Injection state definition → outputs x_inj at t_inj.
3. Propagator → produces ephemerides across the horizon.
4. Geometry engine → converts ephemerides into crossing intervals.
5. Detectability gates → filters crossings into detectable intervals.
6. Scheduler/scoring → converts intervals into mission metrics and ranked opportunities.

3) Shared State Definitions — The Glue

Integration only works if shared state objects are defined clearly and consistently. These must be explicit (because ambiguity here breaks everything downstream):

• t0 — UTC liftoff time
• t_inj — injection epoch
• x_inj — injected state vector or orbital elements
• Frames — ECI/TEME/ECEF stated clearly (never implicit)
• Crossings = [(t_start, t_end), ...]
• Detections = [(t_start, t_end), ...]
• Constraints: sunlit, range, slew, duty cycle, station-night (if ground-based)

F.10 Algorithm — Coarse-to-Refine Integrated Evaluation

Reuse the core principle from F.7–F.9: reject cheaply, refine only when necessary, and store event intervals instead of dense time-series booleans.

# coarse grid scan -> candidate windows -> refine -> interval extraction

t_coarse = grid(t0, horizon=48h, dt=60s)
propagate(sensor, object, t_coarse)

candidate = relaxed_range_gate & relaxed_fov_gate
cand_windows = boolean_to_intervals(t_coarse, candidate)

crossings = []
detections = []

for w in cand_windows:
    t_fine = grid(w.start-pad, w.end+pad, dt=10s)
    propagate(sensor, object, t_fine)

    C = fov_crossing_boolean(t_fine)
    crossings += boolean_to_intervals(t_fine, C)

    D = C & sunlit(t_fine) & strict_range(t_fine) & slew_ok(t_fine) & duty_ok(t_fine)
    detections += boolean_to_intervals(t_fine, D)

metrics = summarize(crossings, detections)
event_table = build_event_table(crossings, detections, metrics)

Mission-facing outputs

• Coverage percentage across 48 hours
• Worst gap duration
• Total detectable minutes per day
• Number of crossings vs detections
• Constraint dominance (illumination vs geometry vs slew)
• Sensitivity: pointing law change or small maneuver insertion

Python Snippet (F.10) — Integrated Pipeline Skeleton

This is intentionally a “glue skeleton,” not a full package. It’s the pipeline shape that matters: coarse scan → candidate windows → refine → interval extraction → metrics.

import numpy as np

def integrated_mission_eval(cfg):
    """
    cfg contains:
      - t0, horizon_hours
      - injection_state (x_inj) or injection_orbit
      - sensor model: FOV, pointing law
      - constraints: rho_max, sunlit model, duty cycle, slew, keep-out zones
      - dt_coarse, dt_fine
    returns:
      - event_table (intervals)
      - metrics (mission-facing summary)
    """

    # 1) Propagate (coarse grid)
    t_coarse = make_time_grid(cfg["t0"], cfg["horizon_hours"], cfg["dt_coarse"])
    sens_c = propagate_sensor(cfg, t_coarse)
    obj_c  = propagate_object(cfg, t_coarse)

    # 2) Cheap gates -> candidate windows (use relaxed margins)
    Cc = crossing_boolean(obj_c["r"], sens_c["r"], sens_c["b_hat"], cfg["fov_half_deg_margin"])
    Rc, _ = range_gate(obj_c["r"], sens_c["r"], cfg["rho_max_km_margin"])
    cand = Cc & Rc
    windows = boolean_to_intervals(t_coarse["ts"], cand)

    crossings = []
    detections = []

    # 3) Refine inside windows only
    for (ta, tb) in windows:
        t_fine = make_time_grid_window(ta, tb, cfg["dt_fine"], pad_s=cfg.get("pad_s", 30))
        sens_f = propagate_sensor(cfg, t_fine)
        obj_f  = propagate_object(cfg, t_fine)

        # 3a) Geometry intervals
        C = crossing_boolean(obj_f["r"], sens_f["r"], sens_f["b_hat"], cfg["fov_half_deg"])
        crossings += boolean_to_intervals(t_fine["ts"], C)

        # 3b) Detectability gates (run only inside crossing windows)
        R, _ = range_gate(obj_f["r"], sens_f["r"], cfg["rho_max_km"])
        S = sunlit_gate(obj_f["r"], cfg, t_fine)
        A = slew_feasible(sens_f, cfg, t_fine) & duty_cycle_ok(cfg, t_fine)

        D = C & R & S & A
        detections += boolean_to_intervals(t_fine["ts"], D)

    # 4) Summaries
    metrics = summarize_metrics(crossings, detections, cfg)
    event_table = build_event_table(crossings, detections, metrics)

    return event_table, metrics

F.11 — Interview-Level Integrated Case Study

F.11 demonstrates structured engineering reasoning under constraints. It should read like an interview response: fast scan, traceable logic, measurable conclusion.

1) Problem statement

2) Assumptions & constraints

Declare assumptions before conclusions — like a real engineering discussion.

3) Reasoning chain (explicit domain links)

• F.4: injection timing and plane alignment define RAAN/LTAN behavior.
• F.7: propagation produces geometric crossing intervals.
• F.8: detectability gates reduce crossings to feasible observations.
• F.9: coarse→refine + interval storage makes it computationally realistic.

4) Failure modes & mitigations

• Launch timing error → RAAN/LTAN mismatch → lighting degradation
  Mitigation: tighten launch window selection + time-tag consistency checks.
• Coarse step misses short crossings → missed windows → wrong coverage conclusion
  Mitigation: refine only inside candidate windows; boundary search on AOS/LOS.
• Eclipse dominates → detections collapse
  Mitigation: alternate pointing law, add sensor type, or multi-sensor configuration.
• Slew limits violated → schedule infeasible
  Mitigation: reduce tasking density; prioritize; widen FOV strategy.

5) Metrics summary

• #crossings, #detections
• total_detectable_time, worst_gap_duration
• min_range_during_detections
• compute_time / throughput

6) Next improvements (fidelity scaling)

• Use ephemeris-based Sun vector (instead of placeholders).
• Upgrade eclipse model: cylindrical → conical shadow.
• Include $J_2$ precession for longer horizons (LTAN drift realism).
• Add scheduling optimization (priority rules → solver).
• Introduce probabilistic detection models (SNR/attitude uncertainty).

The Domain F Integration Insight

This single sentence ties:

• F.4 — Plane intent (injection timing + plane alignment)
• F.7 — Geometry windows (crossing intervals)
• F.8 — Detectability filtering (illumination, range, constraints)
• F.9 — Scalable event architecture (coarse→refine, interval storage)

It preserves the Domain F mindset: not isolated equations, not isolated modules — a connected mission reasoning pipeline.