Vector™

Vector follows a development to what it reaches, and to the assumptions that would break the chain.

A modelled consequence is a scenario under stated assumptions, and Vector shows it as one. The assumptions are written down, uncertainty is carried rather than rounded away, and no probability is invented.

Vector asks: what happens if this holds?Read the Intelligence Desk

Product scope and availability. These pages describe product roles and intended workflows. Product and source coverage are subject to qualification for each engagement. Production access requires separate approval. Public intake is closed.

When teams use it

When an assessment landsSee what a Material Change™ reaches before deciding how to respond to it.
Planning a captureTrace the timeline, teaming and dependencies a recompete would put in play.
When a supplier is at riskFollow the effect of an acquisition or a lost contract to the programs that depend on it.

A consequence chain, as Vector draws it

Synthetic specimen. No real company, agency or award.
Starts from a Pyrnova™ assessment

The requirement on SPEC-A1 is more likely to be recompeted than extended.

  1. 1Revenue recorded against SPEC-A1 ends with its period of performance on 30 Nov 2026.
  2. 2Subcontract work that depends on SPEC-A1 would need a successor vehicle to continue.
  3. 3A recompete would need capture work to begin before the solicitation is drafted.
  4. AIf an option year is recorded against SPEC-A1 before 30 Nov, the chain does not start.
  5. BIf the successor is set aside for small business, your position as prime changes and teaming becomes the question.
How Vector writes a branch

Each branch names the condition it rests on and what would follow. No probability is attached to it.

Statement kinds Observed fact Pyrnova assessment Hypothetical

Core workflows

What a Vector user does
  1. 01Start from an assessment. A consequence chain begins from a recorded judgement, never from a guess.
  2. 02Trace dependencies outward. Follow the work, revenue and relationships that depend on the development.
  3. 03Read the second-order effects. Not only the immediate consequence, but what that one reaches in turn.
  4. 04Compare scenarios. Set scenarios side by side, each under its own stated assumptions.
  5. 05Check the assumptions. Every branch names the condition it rests on, written as a hypothetical, never as a forecast.
  6. 06Hand off. Open the same chain in Strike™ or Atlas™ without losing your place.

Across Pyrnova

Vector hands off on the same object

Evidence and governance

Kept apart from factA scenario is drawn and set differently from an observed fact, so the two are never confused.
Stated assumptionsEach branch names what it assumes. Change the assumption and the branch says so.
No invented probabilityA likelihood appears only where the evidence supports one.

Related solutions

Supply-chain exposureRecompete monitoring
Read the Intelligence Desk