Inspiration
Film production software is very good at helping teams build schedules, call sheets, and plans. But I became interested in a different question:
What happens after everyone thinks the plan is ready?
A shoot can look perfectly organized and still be surprisingly fragile. A few minutes of setup delay, a hard daylight cutoff, uncertain location access, or a weak assumption can be enough to break the day.
That led to FORESHADOW:
Production software helps you plan tomorrow. FORESHADOW attacks tomorrow.
Instead of generating another schedule, FORESHADOW treats the existing shoot plan like something that needs to be stress-tested.
What it does
FORESHADOW is an operational red-team agent for film shoots.
It takes an already planned shoot day and asks:
How much reality can tomorrow survive?
It identifies operational assumptions, investigates the most important ones using live external evidence, validates whether that evidence is strong enough to use, and then measures how close the shoot is to failure.
Its core outputs include:
- Distance to Failure — how much operational slack remains
- Hard Edge — the verified external boundary constraining the shoot
- Minimum Failure Set — the smallest combination of disruptions that breaks the plan
- Failure Chain — how delays propagate into a boundary breach
- Survival Frontier — which disruption combinations survive and which fail
- Protect This — an intervention that pushes the nearest failure point farther away
The demo shoot in Chennai ends at 18:14. FORESHADOW verifies a daylight boundary of 18:25, leaving only 11 minutes of slack.
A 7-minute setup delay plus a 5-minute lighting reset creates 12 minutes of disruption, which is enough to break the schedule.
How I built it
FORESHADOW separates agentic investigation from deterministic operational math.
Google ADK + Gemini rank existing investigation targets and decide which assumption deserves attention first.
Parallel Search API retrieves live external evidence for those investigations.
That evidence then passes through a validation layer before it can affect any calculation.
The risk engine itself is deterministic. It handles time conversion, slack calculation, risk classification, disruption combinations, minimum failure sets, failure chains, and survival-frontier calculations.
This separation was intentional: the model can decide where to investigate, but it cannot invent evidence or silently alter the final operational arithmetic.
The application is built with TypeScript, Node.js, Express, Google ADK, Gemini, Parallel Search, HTML, CSS, and JavaScript.
Evidence as a design principle
One of the most important ideas that emerged while building FORESHADOW was:
NO EVIDENCE → NO ARITHMETIC
Live web information is often incomplete or ambiguous.
For example, a source may mention a location without giving an explicit closing time, or describe weather without providing a defensible operational delay.
FORESHADOW does not convert vague information into fake precision.
Evidence can be:
- accepted and used,
- rejected and shown as rejected,
- or not investigated within the current investigation budget.
Only validated evidence is allowed into the numerical risk calculation.
Challenges
The hardest part was not simply connecting APIs. It was deciding what the AI should and should not be allowed to do.
Early versions risked becoming a generic AI risk detector. I wanted the system to remain operationally explainable, so I separated investigation, evidence validation, and deterministic calculation into distinct layers.
Another challenge was handling imperfect live evidence. A search result existing does not mean it is safe to use mathematically. Building explicit rejection reasons and provenance became a major part of the system.
I also had to make the agent useful under a limited investigation budget. Instead of searching everything, Gemini ranks the available investigation targets and FORESHADOW spends its budget on the most important one.
What I learned
I learned that agentic systems can become more useful when the model is given clear boundaries instead of unlimited authority.
Gemini is valuable for prioritization and reasoning about where uncertainty matters. Parallel is valuable for retrieving current external evidence. Deterministic code is better for the final arithmetic.
Combining those roles produced something I trust much more than asking one model to do everything.
I also learned that rejected evidence is not a failed result. Sometimes the most responsible output an agent can produce is:
“I cannot justify using this value.”
What's next
The current prototype focuses on a single shoot-day scenario, but the same architecture could expand to additional hard boundaries such as permits, access windows, cast availability, transport constraints, weather thresholds, and location restrictions.
Longer term, FORESHADOW could sit downstream of existing scheduling tools rather than replace them.
Schedulers build the shoot. FORESHADOW tries to break it before reality does.
Built With
- css
- express.js
- gemini
- google-adk
- html
- javascript
- node.js
- parallel
- parallel-search-api
- render
- typescript
Log in or sign up for Devpost to join the conversation.