MarginGuard

Log In

Password: Password1!

Inspiration

Manufacturers constantly deal with outside events they cannot control: port closures, supplier outages, shipping delays, severe weather, and sudden changes in input costs. The problem is not a lack of information. There is already more news and operational data than anyone can realistically keep up with.

The harder question is: What does this event actually mean for my business?

A manufacturer might know that a port has shut down or that severe weather is affecting a supplier region, but still need to figure out which supplier is affected, which components depend on that supplier, which products are at risk, how much money could be lost, and what response makes the most financial sense.

That gap inspired MarginGuard.

MarginGuard is a financial early-warning system for manufacturers that monitors live external intelligence and turns it into traceable business impact.

Instead of simply summarizing what happened, it answers three questions:

Does this affect me? How much money is at risk? What should I do next?

What it does

MarginGuard continuously pulls real-world intelligence from live external sources, including business and supply-chain news as well as active National Weather Service alerts.

Each event is passed through the same analysis pipeline:

Live Event → Supplier → Component → Product → Financial Impact → Recommended Action

For example, if a live weather alert or logistics disruption affects a location used by one of a manufacturer's suppliers, MarginGuard can identify the supplier, determine which components and products depend on it, calculate the potential financial exposure, compare possible responses, and recommend an action.

A result might look like:

A logistics disruption affects Atlantic Packaging, which supplies a critical component used by two products. The estimated margin exposure is $24,500. Switching suppliers would cost $7,200 and produce a better financial outcome than waiting or expediting inventory.

MarginGuard also knows when not to raise an alarm. If a live event does not intersect with the company's supplier, geographic, commodity, or product dependencies, it can return No Material Exposure Detected rather than forcing every headline into a risk alert.

Users can inspect the source evidence behind an event, the dependency path connecting it to the business, the formulas behind financial calculations, and the reasoning used to compare response options.

How we built it

We built MarginGuard as a complete end-to-end web application using a serverless AWS backend.

The frontend uses Next.js, React, TypeScript, and Tailwind CSS. The interface is organized around a simple decision flow:

Detect → Trace → Quantify → Decide

Our backend uses Amazon API Gateway and AWS Lambda to process requests and run the analysis pipeline. Amazon DynamoDB stores company, event, and analysis data, while Amazon S3 is used for source and evidence storage.

Live Intelligence

MarginGuard does not rely entirely on hardcoded demo events.

We integrated live upstream intelligence sources, including:

NewsAPI for current business, manufacturing, logistics, and supply-chain news
National Weather Service API for active weather and geographic disruption alerts

These external sources are normalized into a common internal format and sent through the same pipeline used by our deterministic demo scenarios.

That means a live article or weather alert can be:

retrieved from an external API,
analyzed by Nemotron,
matched against the company's dependencies,
quantified by the financial engine,
converted into response options,
stored and displayed in the application.

We kept a deterministic Judge Demo alongside live intelligence so the application remains reliable even if an external provider is temporarily unavailable.

NVIDIA Nemotron

For the intelligence layer, we use NVIDIA Nemotron as more than a chatbot.

Nemotron performs structured tasks such as:

classifying events,
extracting companies, locations, and other entities,
identifying source evidence,
determining whether an event is relevant to the business,
and reasoning over pre-calculated response options.

One of the most important architectural decisions we made was separating AI reasoning from financial calculation.

Nemotron does not generate financial values.

Instead, MarginGuard uses a deterministic financial engine based on explicit company data such as product volume, supplier dependencies, contribution margin, disruption duration, and response costs.

For example:

For example, MarginGuard calculates Margin at Risk as:

$$ \text{Margin at Risk} = \text{Affected Units} \times \text{Contribution Margin per Unit} $$

Because these calculations come from deterministic code, users can inspect exactly how a financial number was produced instead of trusting a value generated by an LLM.

We also built a What-If simulator that lets users change assumptions such as disruption duration or supplier dependency and immediately see how financial exposure and the recommended action change.

Evaluation

We created a labeled evaluation dataset to test the Nemotron intelligence pipeline rather than simply assuming that the model works.

Our evaluation framework measures areas such as:

event classification,
relevance detection,
entity extraction,
structured-output validity,
and false-positive behavior.

We also expose failed evaluation examples so the model's limitations are visible instead of presenting the AI as perfect.

Challenges we faced

One of our biggest challenges was scope.

It would have been easy to turn MarginGuard into a huge platform for every possible financial or supply-chain risk. Instead, we focused on building a smaller number of workflows that work completely from live data ingestion through financial decision-making.

Another challenge was making AI output trustworthy.

A system that confidently invents a financial loss would be worse than having no estimate at all. We solved this by strictly separating responsibilities: Nemotron interprets and reasons about external information, while deterministic code handles financial calculations.

Connecting external events to a specific company was also challenging. A flood warning or port disruption alone does not prove financial exposure. MarginGuard has to trace the event through geography, suppliers, components, and products before calculating an impact.

Live APIs introduced another challenge: real data is unpredictable. External providers can fail, return irrelevant events, or produce incomplete information. We designed MarginGuard so provider failures do not break the application, irrelevant events can be safely rejected, and deterministic demo scenarios remain available as a fallback.

Finally, we spent significant time improving the user experience. Early versions exposed too much information at once. Reorganizing the application around:

Detect → Trace → Quantify → Decide

made it much easier to understand what happened, why it matters, how much is at risk, and what action should be considered.

What we learned

The biggest lesson we learned was that adding an LLM does not automatically make a system intelligent.

The most useful AI systems combine different types of computation. In MarginGuard, AI is good at interpreting messy real-world information, while deterministic software is better suited for financial calculations and business rules.

We also learned how important traceability is when AI is involved in business decisions. Showing a recommendation is not enough. Users should be able to inspect the evidence, assumptions, calculations, and reasoning behind it.

Building the live intelligence system also taught us the importance of designing around imperfect external data. A useful monitoring platform cannot assume every source is available or every event is relevant.

On the engineering side, we gained experience building and connecting a complete application across frontend development, AWS serverless infrastructure, live external APIs, structured LLM outputs, financial modeling, data validation, persistence, and model evaluation.