01 · PRODUCTWHAT IT IS2026
// WHAT SPACE REDI IS BUILDING

The operational intelligence layer for spacecraft autonomy.

SPOK builds how the vehicle actually works from your engineering data, joins it to the mission, the flight rules and the world outside, connects it to live vehicle state, and shows the information pathway behind every answer.

01 · ONE MODEL, THREE LAYERS

Take control of your information environment.

Everything an operations team decides on is information. Today it lives scattered across documents, tools, flight software, and the heads of the people who built the vehicle. SPOK puts it in one place, seen by everyone.

SPACECRAFT MODEL
How the vehicle works
Source-traceable engineering truth: components and connections, interfaces, limits, commands and effects, failure modes, live state.
SCHEMATICS · SPECS · ICDs
FMEA / FMECA · FLIGHT SW · TELEMETRY
INFORMATION ENVIRONMENT
What else matters
The vehicle is only part of it. Mission needs, flight rules and the world outside join the same model, so every decision weighs everything that bears on it.
PROCEDURES · FLIGHT RULES
MISSION CONTEXT · WEATHER · SDA
OPERATIONAL MODEL
What to do about it, and why
The NASA flight operations decision process, encoded as a pathway from alarm to evidence-backed action.
ASSESS · OPTIONS · RISK
RECOMMEND · EXECUTE · STAY AHEAD
02 · THE QUESTIONS IT ANSWERS

In the order a flight controller asks them.

1FAILURE
What happened?
What is the signature, and what does it mean? What are the possible causes? Is any immediate safing action required?
2IMPACT
What does it mean?
What redundancy have we lost? What is the time-to-effect? Which mission objectives does it threaten?
3WORKAROUND
What do we do about it?
What regains function, by when, and is “do nothing” viable? What does each option risk? What is the recommendation, and the backup plan?
4NEXT WORST FAILURE
What fails next?
Which failures hit harder in this configuration? Is there any action we can take now to make the vehicle safer?
ONE INFORMATION PATHWAY · EXAMPLEWHAT WE KNOW VS. WHAT WE THINK
  1. CAD
    Solar array orientation
    P = G·A·η·cos θ
  2. SCHEMATIC
    EPS bus power deficit
    dE/dt = PGEN − PLOAD
  3. TELEMETRY
    Battery reserve falling
    SOC < limit → payload inhibit
  4. FLIGHT SOFTWARE
    Camera power shed
  5. MISSION OBJECTIVE
    Imaging pass at risk
  6. RECOMMEND
    Shed heater margin, preserve pass

Every answer carries its evidence and the model links behind it. Each step cites a schematic, FMEA, rule or feed, or is flagged as a gap.

03 · WORKING WITH SPOK

Start with what you have. Widen the envelope as the model proves itself.

  1. STEP 1
    Start with what you have
    CAD, schematics, ICDs, FMEA, flight software, telemetry, procedures, mission plans, weather and SDA feeds, as they are, under your access controls.
  2. STEP 2
    We build the model
    One connected model of the vehicle, its mission, and the environment it operates in. Every claim traces to a source or flags an open gap.
  3. STEP 3
    Review the gaps
    Your first deliverable: a list of what your documentation does not say about your vehicle, before it matters on orbit.
  4. STEP 4
    Fly with it on console
    Failure, impact, workaround and next worst failure on demand. Every recommendation packaged with options, costs, risks and a backup plan.
  5. STEP 5
    Widen the envelope
    As the model proves itself, responses move from advisory to automated. Anything outside the envelope escalates to you.
04 · BUILT TO BE CERTIFIED

Autonomy that can explain itself.

THE CERTIFICATION TESTBLACK-BOX AISPOK
Can you list every behavior it can produce?Outputs can’t be enumeratedEvery behavior is a path through an explicit model
Can you trace each answer to a source?Nothing inside points to a spec or a flight ruleEvery step cites a schematic, FMEA, rule or feed
Same inputs, same answer, every time?Can change even with the same inputsDeterministic: testable and bounded
Who can sign off on it?Nobody, yetYour mission assurance board, today
Traceable by construction
Every link from any input to the decision is derived, source-backed, or flagged as a gap. Audited step by step, not trusted on a score. No LLMs or black-box neural networks in the loop.
Operator DNA
Built on the doctrine NASA trains on console: Failure–Impact–Workaround, Next Worst Failure, team situational awareness. Operations led by a former NASA flight controller.
Sits on top of what you fly today
Works alongside existing command and control software. No rip-and-replace for operators, and each mission modeled adds reusable vehicle, rule and environment patterns.

See what your documentation doesn’t say about your vehicle.

REQUEST EARLY ACCESS →