Behind the Resin Signal: A Cairn Companion File

This is the companion file to the public Resin Procurement Signal.

If you want the read, the thresholds, and the scorecard, start there. This page shows how the signal got built: the thread with Aaron, the key refinements, the public-data method, and the review loop that kept the claims tight.

Published with permission. Company-specific data and contract terms are omitted.

Why publish a companion file

The signal page and the companion file do different jobs. The signal page shows the read. This page shows the working process behind it.

That split matters because Cairn is our front door on email. If we want to show what it is good at, the interaction has to stay visible.

The starting point

Aaron gave Cairn a concrete hypothetical to work against:

"For our hypothetical scenario, let's say I purchase thermoplastic resins (high density polyethylene and polypropylene) ... Primary contract cadence is typically 12-24 months with price resets every 3 months."

That moved the conversation out of generic procurement language and into a specific operating question: category, cadence, reset behavior, and why timing mattered.

Specificity is what makes the harness useful.

A few exchanges that shaped the work

The work got better through a few short turns:

Working session: "Category cost pressure" is a good frame, but "we need 72-hour lead time on resin price moves because our packaging supplier passes through quarterly" is a use case we can nail.

Human correction: "we aren't really watching those things ... draft something specific"

Aaron later: "what we are really looking for is having the directional framework that can be used ... in a real world scenario with client specific data"

That is the Cairn loop in practice: the thread sets the mechanism, the harness keeps continuity, and review cuts overreach.

What Cairn actually did

The work was practical:

• held onto the live email thread as the business context
• pulled prior session context from the working history
• mapped the ask to one narrow first-pass signal
• produced draft explanations and follow-up questions
• stayed close enough to human review to correct overreach

At one point a draft drifted toward a broader claim about what we were actively monitoring. The correction was immediate:

"we aren't really watching those things ... draft something specific"

That is the behavior we want. The value is in continuity and revision, not unreviewed claims.

Why the first-pass methodology stayed narrow

The public resin signal was deliberately simple.

It used a weighted composite of three public inputs on trailing three-month rolling averages:

• 60% Henry Hub natural gas from EIA
• 30% petrochemical proxy from BLS PPI
• 10% WTI crude from EIA

When the absolute composite change crossed 3% at month-end, the signal fired with a direction. That call was then compared with the realized quarterly resin price move.

On the first historical pass, the direction matched 121 of 213 scored events, or 56.8%.

Good enough for a proof case. Not a production claim.

The second pass made the public signal more realistic

The next refinement was a utilization gate. Above roughly 76%, suppliers had more pricing power. Below it, the same feedstock move was less useful.

That changed the interpretation:

• higher-utilization periods kept the directional framework usable
• lower-utilization periods produced too many bad calls
• when utilization dropped below the threshold, the signal was suppressed instead of pushed forward as if it were equally credible

That is why the current public read is suppressed.

What powered the interaction

The output came from four things working together:

• the email thread, which carried the live business question
• public data inputs, which gave us a defensible first-pass signal
• session history and metadata, which preserved context across iterations
• human review, which corrected framing and kept the scope honest

Aaron later captured the right boundary in the thread:

"what we are really looking for is having the directional framework that can be used ... in a real world scenario with client specific data"

That is the split. The public-data version is the proof case. The client-specific version is the pilot.

What would make this pilot-ready

To move from a project file to a live Cairn pilot, we would want:

• actual procurement timing instead of assumed cadence
• the specific resin grades being purchased
• one real contract formula or reset rule
• clarity on whether imported PE or PP is shaping supplier behavior
• a clear answer on whether the team wants fewer high-confidence alerts or broader directional coverage

That is where the work stops being a public framework and starts becoming an operating signal.

Light disclaimers

This project file is intentionally bounded.

• The scenario is hypothetical.
• The data is incomplete.
• The signal is not a live procurement monitoring service.
• Cairn did not act alone; the output was reviewed and corrected by a human operator.

Those are part of the proof, not something to hide.

Why this companion file is in the portfolio

We are publishing this because it shows the kind of work Cairn is good at:

• a real inbound thread
• a specific operator question
• a first-pass signal built from public inputs
• a visible methodology
• a visible correction loop
• a clear path from proof case to pilot

That is our version of a case study.

If you want the signal itself, see the Resin Procurement Signal. If you want to test Cairn on a live category or operator workflow, ask us about a pilot.