Red Eagle — Devpost submission narrative

Inspiration

Supply-chain teams operate under written policies, but the moment demand changes or a route fails, those policies are translated manually across PDFs, spreadsheets, planning tools, chat messages, and approval threads. That creates a dangerous gap between what a policy says, what an operator decides, who authorized it, and what actually changed.

We were also uncomfortable with a second shortcut: giving a general-purpose model control over consequential operational decisions. A model can interpret ambiguous language, but it should not silently calculate inventory, choose a warehouse, approve a transfer, or mutate business state.

Red Eagle was inspired by a simple principle: use AI where language is ambiguous, and deterministic software where consequences are real. We wanted one evidence chain from the exact policy clause to an authorized action and a ledger-verified outcome.

What it does

Red Eagle is a governed policy-to-action platform for supply-chain operations.

It begins with an actual policy PDF. The selected AI runtime compiles that document into a strict PolicyRule, and Red Eagle rejects the result unless the returned quotation matches the extracted source text. From that point onward, deterministic code owns the workflow.

In the included fictional MediCore Pharma workspace, a reviewer can:

1. compile and citation-verify a three-page inventory resilience policy;
2. ingest a synthetic Mumbai demand signal into persisted state;
3. calculate a 1,900-unit safety-stock gap;
4. reject unsafe source facilities with visible arithmetic;
5. select Chennai as the source and calculate an allowed route;
6. close the direct route, preserve the original recommendation as superseded, and create a replacement route through Bengaluru;
7. prove that a Planner receives a backend authorization denial;
8. sign in separately as an Approver;
9. approve and create an internal stock transfer order;
10. confirm dispatch and receipt; and
11. verify the outcome from balanced source and destination inventory-ledger entries.

Every important action is persisted and appears in the Activity trail. MediCore and its inputs are clearly labelled fictional and synthetic; the Red Eagle workflow is real internal application behavior.

How we built it

Red Eagle uses a deliberately compact architecture:

• Frontend: React 19, TypeScript, Vite, TanStack Query, Radix UI, Phosphor Icons, and Leaflet.
• Backend: FastAPI, Pydantic, SQLAlchemy, synchronous SQLite state, PyMuPDF extraction, and NetworkX routing.
• AI runtime: an explicit USE_GPT5_6 switch selects either OpenAI GPT-5.6 Luna or NVIDIA NIM with openai/gpt-oss-120b.
• Structured policy compilation: both paths use the Responses API through the OpenAI Python SDK and parse directly into the same strict PolicyRule model.
• Persistence and authorization: backend sessions, role enforcement, decisions, activity, transfer orders, and inventory-ledger entries are stored in SQLite.
• Deployment: Docker Compose builds the FastAPI backend and Nginx-served React frontend and persists workspace state in a named volume.

The AI prompt explicitly forbids inventory calculation, warehouse or route selection, authorization, order creation, and state mutation. Even then, Red Eagle does not rely on the prompt as the security boundary: deterministic application code and backend authorization enforce those responsibilities.

Challenges we ran into

The hardest challenge was making the AI useful without making it authoritative. A structurally valid response was not enough; we needed the same strict schema across providers and an exact source-evidence check before policy state could be accepted.

We also had to distinguish a convincing demonstration from a simulated workflow. The MediCore inputs are synthetic, but event ingestion, decision versioning, authorization, transfer-order state, inventory mutations, and verification are real persisted application operations. We isolated all MediCore-specific data under demo/medicore/ so the Red Eagle platform and the fictional customer scenario remain conceptually separate.

Route disruption created another challenge. We did not want a changed route to overwrite the original recommendation. Red Eagle therefore locks the earlier decision as superseded and creates a new version, preserving the audit trail.

Finally, the demo needed to be understandable in minutes. We designed the interface around five routes—Overview, Network, Decisions, Policies, and Activity—while keeping fictional-data disclosures and responsibility boundaries visible.

Accomplishments that we're proud of

• A complete policy-to-ledger workflow that is persisted rather than faked in the interface.
• Strict AI responsibility: the model interprets policy and nothing else.
• Exact quotation verification against the extracted policy source.
• Deterministic inventory arithmetic, candidate evaluation, graph routing, and route replanning.
• Preserved decision history when new events invalidate an earlier recommendation.
• A real Planner denial and a separate Approver session enforced by the backend.
• Internal transfer-order states from Created to Dispatched to Received.
• Balanced inventory-ledger entries and an outcome verified from ledger evidence.
• Fail-closed provider selection with no fixture response and no silent cross-provider fallback.
• A responsive, professional interface and a clean Docker setup that judges can run locally.
• A useful preprocessed historical record that prevents the workspace from looking empty while remaining clearly separate from the live walkthrough.

What we learned

We learned that AI safety in operational software is primarily an architecture problem, not just a prompting problem. The safest design was to give the model a narrow, reviewable transformation and place deterministic code around every consequential action.

We also learned that explainability becomes much stronger when evidence is treated as a product feature. Showing the source quotation, calculation inputs, rejected alternatives, route version, human authority, transfer state, and ledger result creates a narrative that both operators and engineers can audit.

Finally, synthetic data and real application behavior can coexist honestly. Clearly labelling the fictional customer while persisting the workflow allowed us to build a repeatable demonstration without misrepresenting an external integration or real company operation.

What's next for Red Eagle

The next step is to connect the same governed workflow to real enterprise systems without weakening its responsibility boundaries. Future work includes authenticated WMS/TMS and ERP connectors, customer-specific policy packs, multi-tenant isolation, configurable approval chains, policy versioning, stronger observability, and production deployment hardening.

We also want to expand beyond stock transfers into other policy-governed operational decisions such as allocation, exception management, supplier escalation, quality holds, and service-level recovery. The long-term vision is for Red Eagle to become the evidence and authorization layer between operational intelligence and real-world execution.

Built With

• codex
• gpt-5.6