Pre-Flight
Predictive impact analysis grounded in your actual environment. Pre-Flight simulates proposed changes against real config snapshots and tells you exactly which humans, service accounts, and integrations would break — before anything touches production.
Design Studio
What should we build
Pre-Flight
What will actually break
Implementation Studio
How do we build it
Step 1
Connect your environment through Key Management. Pre-Flight gets read-only access to live config — IAM policies, identity provider state, network rules, SaaS tenant settings. Nothing is modified.
Step 2
The Systems Architect ingests the live configuration of every affected system — who has access, what depends on what, which integrations are wired in, what policies are enforced.
Step 3
The design from Studio gets applied as a simulation against the real config snapshot. No sandbox, no guesswork — the same rules engine your systems use, run against actual state.
Step 4
Every check resolves to Pass, Fail, or Inconclusive with evidence. You get affected actor lists, stat rows, charts, and specific recommendations — not a text dump.
These aren't hypotheticals. These are the things that blow up two weeks into an implementation because nobody checked.
AWS IAM
Tighten S3 access for the data team
3
Affected roles
3
Pipelines at risk
3
Silent failures
Glue ETL job
glue-etl-prod-role assumes s3:GetObject on data-lake-raw/*. New policy removes this. 3 nightly pipelines break silently.
Snowflake integration role
snowflake-storage-integration reads from data-lake-curated/. Revoking s3:ListBucket kills the external stage.
SageMaker notebook
ds-team-notebook-role writes to data-lake-experiments/. New deny statement blocks PutObject. Model training halts.
Snowflake
Migrate from password auth to OAuth / SSO
14
Orphaned accounts
1
Privilege escalation
8
Needs triage
14 accounts without Okta identity
14 human accounts have no matching Okta profile. They lose access on cutover day with no fallback.
Tableau — hardcoded password on ACCOUNTADMIN
Tableau Server embed uses a service account with password auth and ACCOUNTADMIN. OAuth migration breaks the dashboards and exposes a privilege escalation.
Key-pair auth users
8 service accounts use RSA key-pair auth. These don't need OAuth migration but need separate handling — Pre-Flight can't verify key rotation status without Vault access.
Cloudflare
Add Browser Isolation for risky categories
4
Blocked tools
2
Broken workflows
1
Intermittent issues
Internal tools via device posture
Browser Isolation triggers on "Uncategorized" — which includes 4 internal tools behind Cloudflare Access. Device posture check + isolation = double gate. Users on managed devices get blocked.
Dev workflow — pastebin, transfer.sh
"File Sharing" category isolates pastebin.com and transfer.sh. Engineering uses both daily for incident response. Isolated rendering breaks clipboard paste into terminal.
Marketing adtech scripts
"Advertising" category isolation intermittently breaks third-party tracking pixels on the marketing site. Impact depends on which adtech vendors load scripts client-side.
Every finding is a structured artifact. Verdicts you can act on, data you can export, recommendations that reference the specific config line that matters.
Every check resolves to Pass, Fail, or Inconclusive. No ambiguity. The verdict carries the evidence that produced it.
Not "some users may be affected." You get the exact roles, service accounts, integration names, and human identities that break.
Quantified blast radius. How many accounts, how many pipelines, how many integrations. Rendered inline, not buried in prose.
Not "review your IAM policies." You get "add s3:GetObject for data-lake-raw/* to glue-etl-prod-role before cutover."
Visual representation of what connects to what, and where the proposed change severs a dependency.
Every Pre-Flight report is structured data. Feed it into your change management workflow, attach it to a ticket, or hand it to the implementation agent.
Type a question in plain English. Pre-Flight interprets the intent, identifies which systems to check, runs the simulation, and returns a structured finding.
“Will this WAF rule block our mobile app?”
“Which service accounts lose access if we enforce MFA?”
“What happens to our Datadog integration if we rotate the API key?”
As you design in Studio, the Systems Architect spots risks you haven't asked about. It proposes pre-flight checks mid-conversation and runs them automatically when you approve.
You mentioned tightening S3 bucket policies
SA proposes: Check cross-account Glue access before applying deny
Design includes SSO migration
SA proposes: Enumerate accounts without IdP mapping
Network policy change detected
SA proposes: Validate internal tool accessibility under new isolation rules
Pre-Flight checks aren't static. When the design changes mid-conversation, affected checks become stale and get re-run automatically. The report always reflects the current state of the design, not the version from three messages ago.
Design scoped: Tighten S3 access for data-lake-raw/*
Pre-Flight check: IAM impact analysis
3 FailDesign updated: Add exception for glue-etl-prod-role
Check stale — re-running IAM impact analysis
Pre-Flight check: IAM impact analysis (v2)
2 Fail, 1 PassDesign updated: Add exception for Snowflake integration role
Check stale — re-running IAM impact analysis
Pre-Flight check: IAM impact analysis (v3)
1 Fail, 2 PassBy the third iteration, the design has exceptions for Glue and Snowflake. The only remaining failure is SageMaker — which needs a scoped IAM policy, not a blanket exception. Pre-Flight tracked the delta across every revision.
Ground every design against your live environment. Know exactly what breaks, who's affected, and what to fix — before implementation begins.