Inspiration
A four-day application window colliding with an immovable shooting schedule is not just a research problem. It is an operational production problem.
Film-incentive information arrives as government announcements, program guidelines, and lengthy PDFs. But a production finance team needs answers shaped around its own projects: Does this change apply to our film? What preliminary financial value is at stake? What requires professional review? What should happen before someone treats a purchase as qualified spend?
I wanted to connect those two worlds without giving a language model unchecked authority over financial decisions.
SECOND UNIT turns changing public film-incentive evidence into production-specific, deterministic, human-approved operational controls.
What it does
SECOND UNIT connects evidence discovery, rule interpretation, project-specific evaluation, human approval, and purchasing safeguards in one traceable workflow.
The demonstration evaluates the same captured program update against two fictional productions:
- SALT FLATS: A feature film receives ACT NOW, with a preliminary credit estimate of $2,975,000, calculated deterministically from an $8.5 million qualified-spend basis × 35%.
- NORTHWIND: A relocating television series receives NEEDS REVIEW, with $0 present decision effect, because the retrieved evidence does not establish the applicable relocating-series provisions.
NORTHWIND's result is not a declaration that the production is ineligible. It means the system will not invent an unsupported answer.
For SALT FLATS, the production finance lead can inspect the governing evidence, calculation, source provenance, and determination before explicitly approving an operational action.
That approval causes a separate private Executor service to create a filing task and a qualification hold atomically.
The demonstration then moves into a separate Purchase Order Console. An operator attempts to classify a $340,000 purchase as projected qualified spend. The active hold causes the backend to return a real HTTP 409 Conflict.
The production and transaction are fictional. The backend enforcement is real.
The result is more than an advisory message: a reviewed decision changes what a connected production workflow is allowed to do.
How I built it
All project-specific code implementation was performed using Google Gemini through Google Antigravity.
The application's LIVE pipeline has clearly separated responsibilities:
Parallel Search and Extract retrieve the evidence. Search discovers authoritative public program sources, while Extract retrieves the governing document text for downstream validation.
Gemini on Vertex AI reads and structures the language. It converts source material into schema-constrained candidate rules, dates, and eligibility conditions. It does not choose the final statutory rate, calculate the financial result, approve the action, or execute a hold.
A deterministic Python engine makes the application decision. It evaluates versioned production facts against the supported rules and uses Decimal arithmetic for financial calculations.
Seven evidence gates check source authority, verbatim support, schema validity, permitted ranges, operative status, source conflicts, and captured-content integrity and extraction completeness.
A human authorizes the operational consequence. The finance lead reviews the evidence-backed determination before approving execution.
A private Executor enforces the approved control. It has no Parallel API key, no Vertex AI permissions, and no language-model execution path.
The application is deployed as two isolated services on Google Cloud Run. Service-to-service requests use Google Cloud identity tokens and HMAC request signing.
The backend uses Python, FastAPI, Pydantic, and SQLite. The Decision Center and Purchase Order Console use React, TypeScript, Vite, and Tailwind CSS, with both interfaces served from the same origin to preserve the authenticated demonstration session.
Challenges I ran into
Incomplete retrieval can look deceptively successful
An early extraction reached its configured 100,000-character ceiling while processing the governing guidelines. The response contained substantial text, but the system could not treat it as complete.
The evidence gate failed closed and blocked approval.
Increasing the extraction ceiling to 200,000 characters allowed retrieval of 110,441 characters without hitting the limit.
This became an important lesson: a successful API response is not, by itself, sufficient evidence for a consequential decision.
Reproducibility requires more than saving a response
The canonical LIVE run occurred on August 10, 2026. Replaying its evidence against the host machine's current date would change the meaning of an application-window decision.
The captured replay therefore binds the evaluation to the captured business date and preserves the original source artifacts, hashes, search/session provenance, and deterministic outcomes.
LIVE execution, captured live replay, and illustrative fixtures remain explicitly distinct.
The safeguard had to work outside the dashboard
Showing “HOLD ACTIVE” on a card would not prove operational enforcement.
The harder requirement was preserving the signed session across the Decision Center and Purchase Order Console, carrying the approved determination across the service boundary, and obtaining the actual backend rejection in the purchasing workflow.
The completed path ends in a real HTTP 409 response, not a simulated warning.
Accomplishments I'm proud of
The strongest result is the complete chain:
Public evidence → structured interpretation → deterministic decision → human approval → private execution → purchasing safeguard.
The frozen release passed 241 backend tests, including 9 captured-replay tests, plus 9 Decision Center tests and 5 Purchase Order Console tests. Both frontend production builds passed, along with linting and type checks.
The hosted workflow was verified through human approval, atomic task-and-hold creation, and the cross-workflow HTTP 409 response.
Equally important, the project demonstrates restraint. The same source event produces a supported preliminary estimate for one production and a request for professional review for another.
What I learned
The most useful agent is not necessarily the one with the most authority.
In this project, AI is valuable for interpreting messy public information. Deterministic code is responsible for calculations and application decisions. A human retains approval authority. A separate service enforces the resulting operational control.
I also learned that provenance, extraction limits, business dates, authentication, and failure behavior are not secondary implementation details. They determine whether an apparently convincing result can be trusted enough to act on.
A system that knows when to stop is more useful than one that always produces an answer.
What's next for SECOND UNIT
SECOND UNIT was intentionally built as a focused, production-ready proof of how agentic research can cross the boundary from information retrieval into trusted operational decision-making. I’m especially interested in seeing where other developers take that pattern: expanding it to additional jurisdictions, production workflows, finance controls, or entirely different domains where public evidence needs to become a deterministic, human-approved action.
For me, the most valuable outcome of the project has been the development process itself. It gave me an opportunity to spend much more time with modern coding harnesses, Google Cloud, Gemini, and providers like Parallel, and to think carefully about where probabilistic AI should stop and deterministic systems should take over.
Since starting SECOND UNIT, I’ve already begun using Parallel in other coding workflows so my development environments can retrieve current web information when solving technical problems. That has probably been the most durable takeaway from the hackathon: not just building one agent, but developing a better mental model for how search, structured AI interpretation, deterministic logic, and human control can fit together in real systems.
I’d be excited to see SECOND UNIT evolve through the open-source community, while I continue applying those lessons to other projects and workflows.
Log in or sign up for Devpost to join the conversation.