# Julia Broberg - jbroberg.com > Full site content export for AI assistants. Generated automatically at build time. > Generated: 2026-07-21T20:56:41.970Z ## Home URL: https://jbroberg.com/ JULIA BROBERG · SUPPLY CHAIN ANALYTICS AND GOVERNED SYSTEMS I make global operations run on numbers people trust. Operational intelligence and execution, from the data up - systems and processes that take the strain off people instead of automating the waste. Explore selected systems How I operate OPERATIONAL SCOPE OTD · SIOP · forecasting · inventory The decision cadence a global manufacturer's supply chain runs on, owned day to day. The operator seat - see About SYSTEMS IN PRODUCTION 4systems, with evidence Every one renders from the same governed data spine as this page, with graded outcomes. Counted at build time from the data spine GOVERNANCE Every number graded Each claim on this site carries a confidence grade - verified, reported, estimated, or model - and its source. Enforced by the build, not by good intentions THE ARCHITECTURE Run. Build. Govern. Three lanes, one system: the operating seat earns the credibility, the builds carry it, and governance makes both trustworthy. 01 Run Lead real supply-chain decision processes for a global multi-site manufacturer - the numbers operations actually runs on. On-time delivery reporting the business is held to SIOP and demand forecasting cadence Inventory modeling and stocking decisions Audit-grade reporting over the ERP warehouse The operator seat → 02 Build Turn operational problems into working systems - shipped end to end and running in production, not prototypes. Analytics and decision-support applications Automation and AI workflows with human sign-off Products with locked design systems and grounded AI All rendered from one governed data spine Selected systems, with evidence → 03 Govern Make the systems trustworthy - AI earns trust the way people do, with a record. Human approval gates on anything consequential Audit trails and rollback from the first commit Defensible definitions; every number graded and sourced Kill switches, cost tracking, named accountability How the layer works → THE DECISION INTELLIGENCE LAYER A decision layer, not a dashboard. The same loop runs through everything I ship: five stages a decision moves through, with governance spanning all of them. Sense Signals in: shipments, demand, inventory, commitments - operational ground truth. Interpret Defensible definitions turn raw signals into numbers a team can stand behind. Decide Recommendations meet a human approval gate - a named person stands behind every consequential call. Orchestrate Approved decisions flow into systems and workflows, every action leaving a trail. Learn Outcomes feed back - evaluation, rollback, revised definitions. The loop closes. Govern / Assure Spanning every stage: approval gates, graded evidence, audit trails, rollback, named accountability. SELECTED SYSTEMS Evidence, not decoration. Selected systems render from one governed data spine. The weighting is deliberate: operating platforms first, range second. SUPPLY-CHAIN METHOD Planning demo Multi-site DDMRP planning on synthetic data: one net-flow view, and a policy band for every planned item. VERIFIED Every figure computes live in the browser from scenario inputs; change an input and the whole board recalculates VERIFIED Every named statistical method cites its primary source Governed: Synthetic data only: a fictional manufacturer, invented item numbers and quantities, no real company or client referenced · The pooling direction is a published result; the magnitude is a labeled scenario input, the number I would want challenged first deployed live open the live demo → Agentaction Needsreview? Approvalgate Owner Applied Skipsgate GOVERNED AGENT OPERATIONS JB OS A personal AI operating system - scheduled agents propose, a human approves anything consequential. VERIFIED Scheduled agents run the routine operational work: document ingest, calendar sync, provider cost tracking, and a weekly brief 6 governance mechanisms, on the record Promotion gate Short term Mid term Long term AGENT GOVERNANCE Cortex An agent rebuilt to be quiet: governed memory, owner-only, approval-gated. REPORTED Live in production with vector memory search, in daily use as my mobile interface to project status and open actions 4 governance mechanisms, on the record Owner Decision gate Ops and SC Analyticalseats Advisory seats AGENT ORG DESIGN AI exec team A mini company of expert agents, each on a documented framework. I decide; specialists recommend. VERIFIED Every seat maps to a documented, published framework, and every cited source opens live 6 governance mechanisms, on the record All systems, with their evidence → OPERATING PRINCIPLES What I will not build 01 No dashboard without a decision it serves. 02 No metric without a defensible definition. 03 No automation without an accountable owner. 04 No AI workflow without evaluation and an escalation path. 05 No black box where a consequential decision needs an explanation. THE ARC From analyst to decision infrastructure. Analyst Started where numbers are made: queries, reconciliations, reports that had to be right. Operator Took ownership of the numbers a supply chain runs on - delivery, demand, inventory. Practice builder Built the analytics practice around shared, defensible definitions instead of heroics. System builder Started shipping the missing infrastructure - applications, automation, AI workflows - end to end. Decision infrastructure Now: the governed layer where analytics, systems, and accountability meet. The work is not complete when the model runs. It is complete when the decision improves, the operator trusts it, and the organization can explain why it worked. If you think about systems this way too, say hello. julia@jbroberg.com LinkedIn Agent action approval gate Agent actions split at a decision point: routine work applies automatically; anything consequential waits at a gate for the owner to sign off. Memory tiers behind one promotion gate A candidate memory passes one promotion gate, then settles into a tier and ages from short to long term; contradictions supersede the old memory, they never blend it. Specialist seats under one human decision gate Specialist seats sit under a single decision gate; recommendations rise to the owner, who decides and signs, and every ruling is logged. --- ## All systems URL: https://jbroberg.com/work ALL SYSTEMS The work, in full Four systems, one argument: agents propose, a human decides, and the record survives the decision. Every number below carries a confidence grade and a source. DECIDE What method should drive the decision, and can it be checked? RUN What can an agent do on its own, and what must a human sign? REMEMBER What is a system allowed to keep, and what happens when facts conflict? SPECIFY How would you staff and govern a whole fleet before writing any of it? DECIDE Planning demo Multi-site DDMRP planning on synthetic data: one net-flow view, and a policy band for every planned item. LIVE Close WHY IT MATTERS This is how I reason about inventory policy across sites - demand signatures, DDMRP buffers, and pooling - the way a global multi-site manufacturer running ten-plus ERP systems actually has to. Halden Forgeworks is a fictional company; the method is real. When each plant plans its own island, two of them buy the same long-lead part from the same supplier and neither can see the other's orders. The supplier reads two jumpy signals for one real demand, both sites carry a full cushion against the same risk, and someone still stocks out. The fix is a shared net-flow view and a policy per item that matches how that item actually sells. I do not demonstrate on an employer's or a client's data. So I invented a manufacturer and rebuilt the method from scratch on numbers I made up. ✓ Governed Live Agentaction Needsreview? Approvalgate Owner Applied Skipsgate RUN JB OS A personal AI operating system - scheduled agents propose, a human approves anything consequential. IN PRODUCTION Close WHY IT MATTERS Scheduled AI agents do real operational work here while I stay accountable for anything consequential. The approval gate is designed into the architecture, not bolted on: an agent proposes, I confirm, and that confirmation is what commits the change. Because it runs on my own operational data, it is shown as a walkthrough on request rather than a public link. Most organizations putting agents into production cannot answer three questions: what did the agent do, when did it do it, and what did it cost. Without those answers you cannot audit the system, you cannot defend it, and you cannot budget it. I built the answer where I could be my own regulator first. Every agent action is logged, everything consequential blocks on a human signature, and provider spend is tracked daily across the whole fleet. ✓ Governed On Request Confidential Promotion gate Short term Mid term Long term REMEMBER Cortex An agent rebuilt to be quiet: governed memory, owner-only, approval-gated. IN USE Close WHY IT MATTERS I retired a working version one because it broke a principle I would not trade, then rebuilt so the constraint was structural rather than a setting. Deciding what a machine is allowed to keep, and proving it later, is the instinct deploying AI safely actually needs. Most AI deployments fail on governance, not capability. The model works; nobody can say what it knows, where that came from, or what happens when two facts conflict. I built Cortex to hold a position on that in code rather than in a slide. Version one worked and I retired it anyway. It violated a principle I was not willing to trade: a system that talks to you unprompted has taken a decision you never delegated to it. Rather than tune the behavior down, I rebuilt so the constraint was structural. Quiet by construction, not by configuration. ✓ Governed On Request Owner Decision gate Ops and SC Analyticalseats Advisory seats SPECIFY AI exec team A mini company of expert agents, each on a documented framework. I decide; specialists recommend. SPECIFIED Close WHY IT MATTERS Eleven seats specified, three written to audition standard. Building the rest earlier would be theater. Most multi-agent systems fail on specification, not model quality, so I write the governance first and let the org chart follow. A specification, not a running fleet. Organizations deploying AI agents assume the risk is model quality. The research says otherwise. Across more than 1,600 execution traces from seven multi-agent frameworks, roughly 42% of failures traced to specification and system design: vague roles, undefined completion criteria, unchecked authority. Not a model problem. A management problem, and one that better models will not fix. The implication for anyone deploying this in an operating company: the design document is the control. So I wrote mine, publicly, before building. ✓ Governed Live I built these on my own data and my own time, where I could afford to be wrong. The constraints are the same ones an operating company faces: nobody can see the confidential inputs, every number has to survive being questioned, and the person who signs is accountable whether or not the model was right. Same problem, lower stakes, so the method got tested before it mattered. Start a conversation Agent action approval gate Agent actions split at a decision point: routine work applies automatically; anything consequential waits at a gate for the owner to sign off. Memory tiers behind one promotion gate A candidate memory passes one promotion gate, then settles into a tier and ages from short to long term; contradictions supersede the old memory, they never blend it. Specialist seats under one human decision gate Specialist seats sit under a single decision gate; recommendations rise to the owner, who decides and signs, and every ruling is logged. --- ## The governed intelligence playbook URL: https://jbroberg.com/ai AI, GOVERNED The governed intelligence playbook The plain version first: these are the rules I build into AI systems so an operation can use them without losing control of its own decisions. Below - how the decision loop gets its intelligence layer, and the primitives that keep it accountable, starting with the one that prevents a breach by architecture, not by policy. GOVERNED INTELLIGENCE The Intelligence Stack Six layers carry the decision loop from raw signal to bounded purpose. A single governance layer runs through all of them - not bolted on after the fact, built into the structure itself. Select any layer, or the governance bar, for detail. Escape or the close button collapses it again. GOVERN / ASSURE Stack layers, bottom to top: Learn, Orchestrate, Decide, Interpret, Sense, Purpose PURPOSE The commitments the loop exists to hold. SENSE Demand signal ingestion. INTERPRET SIOP interpretation. DECIDE Allocation and inventory calls. ORCHESTRATE Site execution. LEARN Forecast correction. The loop runs continuously - Learn feeds its corrections straight back into the next cycle of Sense. Layer detail Close detail Forecast correction. Every cycle ends by scoring itself: forecast error, misses, slippage - fed back into the next cycle's assumptions. Today: Error tracking on the forecasting models. Proposed: Eval suites and drift alarms, so the loop notices its own degradation. We already run this loop today, on humans and Power BI. The gold bar is what is missing. That is what I am proposing to build. GOVERNANCE PRIMITIVE The Meta Rule of Two No single agent session may hold all three: untrusted input, private data access, and an external outbound channel. Any two is contained. All three is a breach waiting to happen. Illustrative - not a scored claim. This is a working simulator of the architecture rule, not a live system status feed. Grant capabilities to the agent session A Untrusted input B Private data access C External outbound channel Resulting architecture state Session diagram Untrusted input Agent Private data Outbound channel Status IDLE Idle. No capabilities granted - nothing to contain. Evals, logs, rollback, and the human review queue are detection and recovery - they fire after something has gone wrong. The Rule of Two is prevention by architecture. It is the fifth primitive. Their four primitives tell you a breach happened and help you undo it. The Rule of Two makes the breach structurally impossible. You want both. GOVERNANCE PRIMITIVE The fiduciary wedge Every decision below has a side. The wedge is the permanent gap between them - it is what keeps a routine reorder and a customer-facing call from ever being routed the same way. The two peaks HIGH-SIGMA -> HUMANS Ambiguous, high-stakes, value-laden decisions stay with named humans. LOW-SIGMA -> AGENTS Routine, reversible, well-bounded decisions route to agents under audit. A named human always stands behind the consequential decision. It is called a wedge because the gap between what AI can do and what it can be held accountable for is permanent. It does not close as models improve. That is why governance is architecture, not a feature. Route a decision Drag a decision chip onto a peak, or select a chip and choose where it routes. Reorder point change Not yet routed Customer allocation Not yet routed Forecast override Not yet routed PO release Not yet routed Humans Agents GOVERNANCE PRIMITIVE The Exception Gate A wide stream of decisions narrows through a single gate. Most continue on their own. A named minority are pulled aside before anything executes. Illustrative - not a scored claim. This is a working simulator of the escalation rule, not a live system status feed. THE RULE Any decision touching money, legal text, or customers-of-record automatically escalates to a named human. Decision flow Autonomous Execution (Low-Sigma) Named Human Fiduciary Incoming decisions Static view - motion is reduced or canvas is unavailable. Same split, same rule. Escalation controls Hover or focus the gate mark to view what triggers escalation. What triggers escalation Close ruleset Any one of these routes the decision to a named human, regardless of where the threshold below is set. Money Any payment, refund, credit, or other financial commitment. Legal text Contract language, terms, or anything that creates a binding obligation. Customers-of-record Any change to the standing or relationship of a named customer account. Policy-flagged anomalies Any pattern the governing policy has flagged as outside normal bounds. Escalation threshold Fewer escalations More escalations 95% Autonomous Execution (Low-Sigma) 5% Named Human Fiduciary At this threshold, 5% escalate to a Named Human Fiduciary and 95% continue as Autonomous Execution (Low-Sigma). illustrative - not a scored claim Automation handles the expected. Humans handle the ambiguous. ARCHITECTURE, NOT ADD-ONS Bolted-on vs designed-in The same organization, two ways of bringing in intelligence. One is stapled onto the org chart that already exists. The other sits exactly where the real work already crosses. Drag the divider, or use the arrow keys, to compare. Or jump straight to either side below. Jump to a view Bolted-on Designed-in Bolted-on and designed-in, side by side AI Current view Both views side by side: automation stapled onto an unchanged org chart on the left, synthetic nodes woven into the flow on the right. Bolted-On: automating the wrong things. Leaving the deepest friction untouched. Designed-In: synthetic nodes at the structural intersections. You cannot achieve an intelligence-led transformation without an honest accounting of the legacy architecture you are building on. Bolted-on automates the wrong things and leaves the deepest friction untouched. My team builds at the intersections because we are the intersections. RECOVERY PRIMITIVE The surgical undo. A version timeline for one agent - prompt, model and policy versioned like software, so a bad change can be undone at the scope of one decision, not the whole stack. Illustrative - not a scored claim. The version timeline, the changelog entries and the violation state below are a working simulation of a rollback flow, not a live deployment log. Version timeline v1.0 v1.1 v1.2 RESTORED v1.3 FLAGGED Policy Violation STANDING BY Changelog v1.3 Policy update: new supplier-communication rule. Illustrative example. Rollback status STABLE Stack running at v1.3, stable. Press Trigger the violation to simulate a policy violation and its rollback. Trigger the violation Reset Revert an agent to last week's prompt, last month's model, or last quarter's policy version without taking the stack down. Kill-switch thresholds and soft-delete windows on every destructive endpoint. Agent versions are software versions: traceable, diffable, recoverable. ORGANIZATIONAL INSTRUMENT The Organizational Equalizer Seven structural dimensions, one board. Move any fader from Legacy toward AI-Native and watch which two dimensions the whole system is actually waiting on. Illustrative starting positions - not a scored claim. Julia's honest scoring lands here after her workshop pass. 4 ▼ AI-NATIVE LEGACY BINDING CONSTRAINT Organizational Drag How much process and legacy friction slows a decision before it reaches execution. 6 AI-NATIVE LEGACY AI Elevation How far AI capability has moved from novelty use into how the org actually works. 5 AI-NATIVE LEGACY Work Architecture Whether work is still organized around fixed roles or around outcomes and flows. 3 ▼ AI-NATIVE LEGACY BINDING CONSTRAINT Firm Boundary Design Where the edge of the organization sits - what stays inside, what runs through partners. 4 AI-NATIVE LEGACY Decision Autonomy How much a team can decide and ship without escalating up a chain. 5 AI-NATIVE LEGACY Network Structure Hierarchy versus a networked mesh of accountable nodes. 6 AI-NATIVE LEGACY Reinvention Cadence How often the org actually rebuilds its own operating model, not just its output. TOTAL 33 out of 70 FOUNDATIONAL WORK NEEDED illustrative - not a scored claim Look strictly at your two lowest dimensions. Every other initiative is gated by them. Reset to illustrative defaults Total 33 out of 70. Foundational Work Needed. I am not asking for a role. I measured the organization. These two dimensions gate every other initiative, and the measurement points at the fix. DEPLOYMENT GATE The readiness matrix Score an agent class on the four detection-and-recovery primitives, one to five, from the legacy firm to the ExO 3.0 firm (the exponential-organization maturity model at full score). Then check the one primitive that allows no partial credit. Score this primitive from 1 to 5 Evals NOT YET SCORED SCORE 1 - THE LEGACY FIRM Manual QA before launch, blind in production. SCORE 5 - THE EXO 3.0 FIRM Continuous synthetic evaluation; auto-halt on drift. 1 2 3 4 5 Logs NOT YET SCORED SCORE 1 - THE LEGACY FIRM Scattered chat threads and isolated app logs. SCORE 5 - THE EXO 3.0 FIRM Immutable correlation IDs spanning the entire loop. 1 2 3 4 5 Rollback NOT YET SCORED SCORE 1 - THE LEGACY FIRM Shut down the entire server to fix the agent. SCORE 5 - THE EXO 3.0 FIRM Surgical prompt and policy reversion with zero downtime. 1 2 3 4 5 Human Queue NOT YET SCORED SCORE 1 - THE LEGACY FIRM A human in every loop, crushing speed. SCORE 5 - THE EXO 3.0 FIRM Humans above the loop, SLA-driven exception management. 1 2 3 4 5 Governance primitive Rule of Two compliance No agent session holds untrusted input, private data access, and an outbound channel at once. Pass or fail only. No partial credit. Rule of Two compliance status, pass or fail PASS FAIL Your scores, stored locally in your browser - illustrative, not a published claim. Reset scores GATE CLOSED Do not deploy a new agent class. Failing: Evals, Logs, Rollback, Human Queue, Rule of Two. Do not deploy a new agent class until you score a 3 across all four rows - and the Rule of Two is pass/fail. Framework vocabulary on this page draws on: openexo.com/book, openexo.com/resource-hub --- ## Approach URL: https://jbroberg.com/approach APPROACH I run the decisions, then I build the system that runs them. Most people do one or the other. Supply chain leaders buy tools they can't build. Engineers build tools nobody with P&L accountability asked for. I sit in the seat, feel the friction, and ship the fix, with a record of how every number was checked. 01 Run The seat, not the sidelines. I lead demand forecasting, SIOP, inventory modeling, and cross-site standardization across a multi-site manufacturing network. Standard decisions are mine. Inventory and cost decisions are shared with Finance. Site deviations from standard require my sign-off. These are the numbers operations actually runs on, and when they're wrong, I'm the one who says so. 02 Build Production, not prototypes. What I build replaces instinct with a number at the moment the decision gets made. Power BI and DAX over the warehouse, Power Apps on Dataverse, Smartsheet, and the pipelines between them. Not a proof of concept that died in a demo, systems people log into on a Monday. 03 Govern Trust is a build requirement, not a review step. The grading, the sign-off, the decision log: all of it exists in the system before anything ships, not bolted on afterward for a reviewer. Governance added at the end is documentation. It doesn't control anything. THE METHOD, IN ONE BREATH 01 Harmonize before you automate. Automating an inconsistent definition just produces wrong answers faster and at scale. 02 Lock the definition, and it becomes the standard. Most cross-site disputes are definition disputes wearing a data costume. 03 Grade every published number. Verified, reported, or modeled. A model labeled as a forecast is a lie with a chart on it. 04 AI proposes. A named human approves. If a decision can't be reconstructed from its trail, it doesn't ship. The artifacts behind this method are live and interactive - the decision loop, the Rule of Two, the exception gate, and the rest. See them on the AI page What this prevents The number that was already used. Every published figure carries a grade for how it was checked. Modeled numbers are labeled as models, never as forecasts. The site that went its own way. Definitions are locked centrally. Deviations require named sign-off, not an email thread that ends in silence. The agent that decided something. In the AI systems I build, the model recommends and files to a decision log. A human holds the pen. Proven on systems I build on my own time, not on an employer's production stack. Where this applies Companies with real operational complexity, multiple sites, and a data function that produces reports nobody trusts. That is one job, not two: sitting in the operating seat and building the layer underneath it. Case studies --- ## About URL: https://jbroberg.com/about ABOUT Julia Broberg - I build the systems, the analytics, and the team a global supply chain runs on. I run supply chain analytics for a global multi-site manufacturer - and I build the governed AI systems on top of it. I make global operations run on numbers people trust. Each stop on this arc carries the story in my own words, and a "Why it matters" line translates it for two readers at once - a leader deciding whether I run a function at the right altitude, and a client deciding whether to trust me with a build. Every figure on this page resolves from a versioned numbers vault, never from memory; if I cannot defend a number, it is not here. Finance taught me to value a business. Operations taught me to run one. Building taught me to ship the systems that connect the two. The order is the argument. THE OPERATOR SEAT I manage data analytics inside the supply chain of a global multi-site manufacturer, leading the team that runs on-time delivery reporting, SIOP, demand forecasting, and inventory modeling. These are the numbers operations actually runs on: what shipped, what will be demanded, what to stock, and whether we kept our promises to customers. The reporting layer is Power BI and DAX over the company's ERP data warehouse, built to survive audit questions, not just to look good in a meeting. THE BUILDER, SECOND Because I run that work, I know exactly where analytics loses time and trust. So I also build - production AI and web systems, end to end, on my own time. The stack is consistent: Next.js, TypeScript, Tailwind, Prisma, Postgres, and Claude Code, deployed to real infrastructure. The builds are live and running: a personal AI operating system where scheduled agents work under human approval gates, and a personal agent rebuilt to be quiet by design - owner-only, and approval-gated on anything it keeps. Every one treats governance as a feature, not an afterthought: approval gates, audit trails, kill switches, and cost tracking are built in from the first commit. THE ARC Valuation and equity research A Nordic boutique investment bank, Stockholm | Junior Analyst and Key Account Manager, Equity Research | Oct 2019 - Aug 2022 I started in equity research, valuing companies and building the investor reports that carried those valuations, forecasts, and market reads to the people making capital decisions. I ran key accounts at the same time, so I learned the number and the person on the other side of it together. I learned to value a business before I ever ran one, and I have not been able to look at an operational decision without seeing the P&L behind it since. WHY IT MATTERS Inside a global manufacturer, this is why I read the supply chain as money and not just movement - a day of lead time or a stocked-out line has a figure attached, and I keep that figure in view. For a client, it means the analytics I build are framed in the terms a decision actually gets made in: cost, risk, and return. The quant-finance master's M.S. Applied Quantitative Finance, University of Denver, Daniels College of Business, conferred Nov 2023 | B.S. Business Administration, Finance, Stockholm Business School, 2022 I went back to formalize the instinct with a master's in applied quantitative finance: financial modeling, FP&A, and the quantitative methods underneath them. It is where valuation stopped being something I did by feel and became something I could defend line by line. The finance foundation came first, in Stockholm; the quantitative layer came second, in Denver. WHY IT MATTERS For a hiring leader, the rigor behind my numbers is credentialed, not improvised - definitions and models built to survive a hard question. For a client, the forecasting and reporting I build comes from someone trained to spot when a model is lying. Analyst to senior analyst A global life-science company | Data Analyst, Supply Chain and Operations (graduate internship), Jun 2023 - Nov 2023; Senior Data Analyst, Nov 2023 - Jan 2025 I moved into supply chain analytics at ground level, writing the SQL data models and the Power BI and DAX dashboards that exposed where value was trapped in the value stream. This is where I first brought AI workflow automation into the reporting itself, using it to speed data prep, documentation, and analysis rather than to replace the judgment sitting on top. I did the plumbing myself before I ever directed anyone else's. WHY IT MATTERS For a leader, it means I am not a manager who lost the hands - I can still open the model and find the bad join. For a client, the systems I specify are ones I have also built - I have shipped the layer underneath, not just drawn it on a whiteboard. Manager, building the analytics function A global life-science company | Manager, Data Analytics and Supply Chain | Jan 2025 - Present I built and led the company's global data analytics and continuous improvement function from scratch, and stood up its first unified global data source by consolidating fragmented manufacturing and supply chain systems into one reporting framework. On top of it I automated replenishment and demand forecasting - forecasting that held backlog accuracy within a 5%Automated demand forecasting held backlog accuracy within a 5% error rate.Resume experience bullet.Validated 2026-07-14 error rate - and automated enough manual reporting to document a 10:1Automated reporting and manual workflows achieving a documented 10:1 cost-savings-to-salary ratio.Resume experience bullet.Validated 2026-07-20 cost-savings-to-salary ratio. The metric governance framework I co-developed made the KPI definitions the standard, not the argument. WHY IT MATTERS For a hiring leader, this is function-owner work: I do not staff an analytics team, I build the analytics function and the governed definitions it runs on. For a client, it means I can stand up governed, decision-ready analytics from zero, not only tune what already exists. The builder years, alongside Independent, on my own time, alongside the day job | Builder and operator | current Because I run the analytics, I know exactly where it loses time and trust, so I build the missing infrastructure myself, end to end, outside work. The systems are live and running: a personal AI operating system where scheduled agents work under human approval gates, and a personal agent rebuilt to be quiet by design, owner-only and approval-gated on anything it keeps. Every one treats governance as a feature from the first commit - approval gates, audit trails, kill switches - and each ships with a passing automated test suite anyone can read on its own system page. WHY IT MATTERS For a hiring leader, it closes the loop: I can build the systems I specify, and I have proven the governance pattern on my own infrastructure before proposing it on anyone else's. For a client, the side work is public and running - proof anyone can inspect, not a folder of screenshots. PRINCIPLES What I will not build No dashboard without a decision it serves. No metric without a defensible definition. No automation without an accountable owner. No AI workflow without evaluation and an escalation path. No black box where a consequential decision needs an explanation. Two lines I will say in the room Evidence discipline. No unvalidated figure leaves my team. Every number I publish is graded by how it was checked and carries its source and date; if I cannot defend it, it does not ship - this page included. Named accountability. AI proposes; a named human approves anything consequential. There is always a person standing behind the decision, and a trail that shows who decided and why. HONEST GAPS Stated plainly, because an honest boundary is evidence too. Here is what I do not have yet, and why it does not sink the case. No director title yet. My title today is manager, not director. But the work already runs at that altitude: I own a global function, its definitions, and its governance, not a reporting queue. The mandate makes that case on the evidence rather than asking you to take a title's word for it. My AI engineering is learned in production, not credentialed. I did not come up through a computer-science degree or an ML certificate; I learned to build governed systems by building them and running them. The evidence is the passing automated test suites on the systems I built and operate outside work, each with its own count and source on its system page - the discipline is real and inspectable, even if the credential is not on the wall. My leadership is at small-team scale. I built the analytics function from nothing - hired it, trained it, not a large organization. What that understates is the reach: the function runs on automation and governed definitions, so its output is not bounded by the number of people - which is the argument for the altitude, not against it. Away from the work, I run ultra-distance on my own two feet - the same discipline, just quieter. COMPETENCIES SUPPLY CHAIN ANALYTICS On-time delivery reporting SIOP Demand forecasting Inventory modeling Revenue-cutoff validation BI AND DATA ENGINEERING Power BI DAX SQL over ERP data warehouses Audit-grade reporting design GOVERNED AI SYSTEMS Human-in-the-loop approval gates AI-proposes-human-approves pipelines Audit trails and rollback AI spend tracking Graded-claims evidence discipline FULL-STACK ENGINEERING Next.js and TypeScript Tailwind Prisma and Postgres Python and FastAPI Deployment on Railway, Netlify, and Vercel --- ## Resume URL: https://jbroberg.com/resume RESUME Julia Broberg I build the systems, the analytics, and the team a global supply chain runs on. Denver, Colorado - working across US time zones and EMEA julia@jbroberg.com LinkedIn Download resume (PDF) WHAT I DO I build the data systems a global supply chain runs on - and I stay for the decisions they feed. The questions I work on day to day are the ones operators bring: why the backlog is growing, which number the room can trust, what a tariff does to margin this week. Continuous improvement, to me, starts with people and process before tools - I find the pain, bring the people who do the work into the fix, and manage the change so it holds. I've built and led a global analytics function across four international sites and automated it, delivering a documented 10:1 cost-savings-to-salary ratio - and I don't automate waste, I remove it first. HOW IT COMES TOGETHER Finance Operations &Supply Chain Technology& AI Full-stackoperator Most operate within one circle. I value it, run it, and build it. Finance valuation, forecasting, and the quantitative methods underneath Operations & Supply Chain multi-site planning, MRP, inventory policy, continuous improvement Technology & AI data pipelines, BI, and production apps with AI kept on a leash WHAT I OWN Data infrastructure & internal tooling One unified data source where there were many, plus the production apps I build and run - not just spec. Vendor Brain - one supplier, many ERP systems, one golden record. OPEN DEMO Forecasting & supply planning Automated MRP, replenishment, and demand forecasting across ten-plus ERP systems - inventory planning that tightens itself. The demand and replenishment models the plants plan against. Data governance Enterprise metric governance - KPI definitions standardized, data-quality standards set, operations made AI-ready. The framework the whole business reports through. Analytics force multiplier I don't just lead the team - I multiply it. Built the analytics function from zero into the enterprise's Center of Excellence - the team the business hands the problems that can't fail. WHAT I WORK WITH AI & LLM TOOLING ChatGPT / GPT Claude LLM-assisted analytics prompt engineering AI workflow automation AI integration LANGUAGES & DATA Python SQL PostgreSQL data modeling ETL / data pipelines KPI & metric governance predictive forecasting BI & ANALYTICS Power BI (DAX) Databricks DAX Studio Smartsheet expert-level Excel APP & DEPLOYMENT STACK Node.js PostgreSQL / Neon (serverless) Railway Render GitHub REST APIs VS Code AUTOMATION & OPERATIONS MRP & replenishment automation automated reporting value stream mapping process mapping forecasting models ERP & BUSINESS SYSTEMS ERP systems (ten-plus instances) Jet Reports Salesforce Microsoft 365 WHERE IT'S PROVEN Built and lead the global data analytics & continuous improvement function Manager, Data Analytics & Supply Chain · Global Life Sciences Company (NASDAQ-listed) · Jun 2023 - Present Walked in as the graduate intern and built what wasn't there: the company's global data analytics and continuous improvement function, from scratch - owning value-stream metrics across manufacturing and supply chain and leading a team of five analysts across four international sites. Across global sites I ran the same lean turnaround - SQL data models and Power BI (DAX) dashboards that expose value-stream bottlenecks. In one, lead time fell from 17 days to 1 day, the backlog shrank from $17M to $7M, and on-time delivery climbed - inside two months. Made AI part of the daily workflow: ChatGPT and Claude alongside Python and SQL, accelerating data prep, documentation, and analysis across analytics and reporting. One source of truth where there were many: built the company's first unified global data source, consolidating disparate manufacturing and supply chain systems into one standardized, AI-ready reporting framework - and harmonized supplier and spend data into its first strategic sourcing platform. Automated the reporting and manual workflows that slowed decisions, with a documented 10:1 cost-savings-to-salary ratio to show for it. Replaced manual production planning across multiple manufacturing sites: designed and deployed automated MRP and replenishment systems that run alongside the company's ten-plus ERP systems. Built the automated demand forecasting and predictive models that held backlog accuracy within a 5% error rate and tightened inventory planning. Ran continuous improvement across global sites the way it sticks: mapped value streams and processes with the people who do the work, standardized the workflows, targeted the waste, and sustained the gains through automated dashboards. Developed and owned the enterprise metric governance framework - KPI definitions standardized, data-quality standards set, and operations made AI-ready with Databricks as the target platform. When tariffs hit, hours mattered: led a 24-hour cross-functional tariff-risk response - repositioning tens of millions in inventory across international distribution centers to protect margin and supply continuity. We shipped far more than usual out of the US sites near year-end and still hit our targets - the customer experience didn't slip, it improved. Mapped the value stream and delivered the analytics behind a two-site distribution center consolidation - a 15% gain in customer satisfaction, completed ahead of schedule. Equity Research & Key Account Management Nordic Boutique Investment Bank · Oct 2019 - Aug 2022 Nearly three years in finance before operations - equity research, valuation, and client coverage inside a Nordic investment bank. It built the muscle I use every day now: turning analysis into a decision someone will act on, and earning trust with numbers that survive scrutiny, in front of clients. Sales and analysis were one job: grew the commissioned equity research service by 170%, driving 4x revenue growth and lifting its ranked overall performance from 5th to 2nd (2021 Kantar Prospera benchmarking). Built investor portfolio reports - valuations, forecasts, market insights - for internal and external stakeholders, and client engagement and satisfaction rose with them. Mentored 10+ junior team members with sales training formally requested by the Head of Corporate Access, improving overall team performance. Recognized as the top salesperson for revenue and client acquisition; featured on a prominent finance podcast with 15,000+ listeners. EDUCATION M.S. in Applied Quantitative Finance, Certificate in Management University of Denver, Daniels College of Business Nov 2023 B.S. in Business Administration, Finance Stockholm Business School Jun 2022 CERTIFICATIONS Company Valuation Stockholm School of Economics Executive Education 2022 Licensee: Information Provider SWEDSEC 2019 Licensee: Specialist SWEDSEC 2021 Investment Analysis & Portfolio Management Finanskursen by Karl-Mikael Syding 2020 LANGUAGES Swedish (fluent) English (fluent) Spanish (conversational) --- ## How I think about fragmented data environments URL: https://jbroberg.com/fragmented-data METHOD How I think about fragmented data environments When I walk into a business running ten-plus ERP systems that don't agree, I don't start by integrating them. I start from the decision that has to be made, then work back to the smallest set of layers that decision depends on. The rule I work by is simple: unify the decision before you unify every system. I read a fragmented environment as three layers. Most of the noise lives at the bottom. The number a decision gets made on lives at the top. I define the top first, then reach down for only what it needs. THE THREE LAYERS Selecting a layer shows what happens there. 3 Decision-ready The number a decision actually gets made on - cost, risk, return. 2 A common model One place the meaning is agreed - a golden record, harmonized definitions. 1 Raw sources The ten-plus ERP systems and spreadsheets that don't talk to each other. A decision reads from the top down. A DECISION TO TRACE Selecting a decision traces it down through the layers it leans on. Can I promise this order? What do we actually spend with each vendor? What do I automate next? AT THIS LAYER Raw sources Down here it's ten-plus ERP systems and spreadsheets that don't agree. I don't try to make them all line up. I find only the sources the decision at the top actually leans on, and I leave the rest alone until a decision needs them. The pattern I build on The layered-refinement idea is not mine to claim. It is the medallion architecture pattern, documented on Microsoft Learn. What I add is the order of operations: I define the decision at the top first, then pull only the layers beneath it that the decision depends on. In a fragmented environment, that ordering is what separates a years-long integration program from one number a decision can actually trust. --- ## JB OS URL: https://jbroberg.com/work/jb-os Part of one argument: agents propose, a human decides, the record survives. GOVERNED AGENT OPERATIONS JB OS: agents doing scheduled work, with a human on the gate A production system where AI agents run on a schedule, ingest documents, sync calendars, track what every provider costs, and compile a weekly brief. Anything consequential stops at an approval card and waits for a person. Agentaction Needsreview? Approvalgate Owner Applied Skipsgate Agent actions split at a decision point: routine work applies automatically; anything consequential waits at a gate for the owner to sign off. WHY IT MATTERS Scheduled AI agents do real operational work here while I stay accountable for anything consequential. The approval gate is designed into the architecture, not bolted on: an agent proposes, I confirm, and that confirmation is what commits the change. Because it runs on my own operational data, it is shown as a walkthrough on request rather than a public link. IN PRODUCTION Walkthrough on request PROBLEM Most organizations putting agents into production cannot answer three questions: what did the agent do, when did it do it, and what did it cost. Without those answers you cannot audit the system, you cannot defend it, and you cannot budget it. I built the answer where I could be my own regulator first. Every agent action is logged, everything consequential blocks on a human signature, and provider spend is tracked daily across the whole fleet. WHAT IT DOES Scheduled functions do the routine work: they ingest documents, sync calendars, track what every AI provider costs, and compile a weekly brief. Routine actions apply automatically. Anything consequential stops, pushes an approval card, and blocks until a person signs. The gate is architectural, not a setting: an agent proposes, and my confirmation is what commits the change. Every pipeline action lands in an append-only audit trail, and provider spend is totaled daily across the fleet. OUTCOMES - EVERY CLAIM GRADED Every claim here is either verified against an artifact I can show you, or marked as my own report. Ask for either. VERIFIED Scheduled agents run the routine operational work: document ingest, calendar sync, provider cost tracking, and a weekly brief each scheduled function invoked directly, with its downstream effects read from the database, 2026-07-21 REPORTED Propose-then-approve runs end to end in the data pipeline: an agent proposes, a person signs, and the signature is what commits the change from the project's own governance records, 2026-07-18 Hide how each was checked GOVERNANCE ✓ Pre-commit boundary enforcement: no real operational data can enter the repository, checked mechanically on every commit ✓ Human approval gates: consequential agent actions block until signed ✓ Propose-then-approve with dry-run transport before anything writes ✓ Append-only audit trail on every pipeline action ✓ Role-based access enforced at the database row level, not in application code ✓ Daily spend accounting across providers, instrumented and scheduled WHAT TRANSFERS The pattern is the same one I would deploy in an operating company: agents handle the routine, humans hold the consequential, every action leaves a record, and the cost is visible daily. Proven here on data I own, where I could take the risk of being wrong. STACK Next.js TypeScript Supabase Postgres with row-level security Scheduled serverless functions Anthropic SDK If you build or hire around systems like this, say hello. julia@jbroberg.com ← All systems Agent action approval gate --- ## Cortex URL: https://jbroberg.com/work/cortex Part of one argument: agents propose, a human decides, the record survives. AGENT GOVERNANCE Cortex: governed memory for an AI agent A working system for the hardest problem in applied AI: deciding what a machine is allowed to remember, and proving it later. In daily use, every claim on this page graded. Promotion gate Short term Mid term Long term A candidate memory passes one promotion gate, then settles into a tier and ages from short to long term; contradictions supersede the old memory, they never blend it. WHY IT MATTERS I retired a working version one because it broke a principle I would not trade, then rebuilt so the constraint was structural rather than a setting. Deciding what a machine is allowed to keep, and proving it later, is the instinct deploying AI safely actually needs. IN USE Walkthrough on request PROBLEM Most AI deployments fail on governance, not capability. The model works; nobody can say what it knows, where that came from, or what happens when two facts conflict. I built Cortex to hold a position on that in code rather than in a slide. Version one worked and I retired it anyway. It violated a principle I was not willing to trade: a system that talks to you unprompted has taken a decision you never delegated to it. Rather than tune the behavior down, I rebuilt so the constraint was structural. Quiet by construction, not by configuration. WHAT IT DOES An agent that learns from conversation accumulates claims. Three questions decide whether that is an asset or a liability: what earns the right to be remembered; what happens when a new fact contradicts an old one; and who can see it, and who can change it. Cortex answers all three explicitly. Candidate memories pass a promotion gate before they enter a tier. Contradictions are resolved by supersession with an audit trail, never silently blended. Access is a fail-closed allowlist. The agent observes state and never writes it. OUTCOMES - EVERY CLAIM GRADED Every claim here is either verified against an artifact I can show you, or marked as my own report. Ask for either. REPORTED Live in production with vector memory search, in daily use as my mobile interface to project status and open actions deploy records and applied migrations verified 2026-07-08; on 2026-07-21 the delivery bot was confirmed present in its server with access to the channel it posts to, not a confirmed send; daily use is my own, not independently measured VERIFIED Full regression suite green at time of last verification test run, 2026-07-18 Hide how each was checked I apply the same split to business cases, and it is the reason my forecasts get trusted. GOVERNANCE ✓ Fail-closed access. The default is deny, not allow. ✓ Reactive only. It answers when addressed and initiates nothing. ✓ Supersession over blending. Contradictions leave a trail. ✓ Read-only bridge. The agent observes the system of record; humans change it. WHAT TRANSFERS The same three questions apply to a demand forecast, a supplier scorecard, or any model whose output feeds a decision someone has to defend: what earns the right to be trusted, what happens when sources conflict, and who is accountable for the change. Cortex is where I work those out in a system I can rebuild from scratch, before applying them where the cost of being wrong is measured in inventory. STACK TypeScript PostgreSQL with pgvector Local embeddings Railway Provider-agnostic LLM routing If you build or hire around systems like this, say hello. julia@jbroberg.com ← All systems Memory tiers behind one promotion gate --- ## How I set inventory policy across sites URL: https://jbroberg.com/work/planning-demo Part of one argument: agents propose, a human decides, the record survives. SUPPLY-CHAIN METHOD How I set inventory policy across sites Three plants, one shared long-lead component, and every item sorted into the policy it earns from its own demand signature. Every number computes live in your browser. Open the interactive demo WHY IT MATTERS This is how I reason about inventory policy across sites - demand signatures, DDMRP buffers, and pooling - the way a global multi-site manufacturer running ten-plus ERP systems actually has to. Halden Forgeworks is a fictional company; the method is real. LIVE PROBLEM When each plant plans its own island, two of them buy the same long-lead part from the same supplier and neither can see the other's orders. The supplier reads two jumpy signals for one real demand, both sites carry a full cushion against the same risk, and someone still stocks out. The fix is a shared net-flow view and a policy per item that matches how that item actually sells. I do not demonstrate on an employer's or a client's data. So I invented a manufacturer and rebuilt the method from scratch on numbers I made up. WHAT IT DOES Every item carries a demand signature: how often it sells, and how much a sale swings when it does. That signature sorts it into one of five policy bands, from standing auto-ship to flagged for human review. Buffers reorder off net flow rather than a fixed point. A toggle plans the shared component two ways, as blind islands or as one pooled network buffer, and shows what the difference costs. The classification, the policy, the buffer zones, and the net-flow status all compute from the raw scenario inputs. Nothing is hand-tuned to look good. OUTCOMES - EVERY CLAIM GRADED Every claim here is either verified against an artifact I can show you, or marked as my own report. Ask for either. VERIFIED Every figure computes live in the browser from scenario inputs; change an input and the whole board recalculates the live demo at /demos/planning/ recomputes every figure from its scenario inputs; checked in a headless browser under the production CSP, 2026-07-20 VERIFIED Every named statistical method cites its primary source the cited primary sources open live; verified 2026-07-20 REPORTED The pooling magnitude is a scenario input encoding partial correlation. The direction is a published result; the size is mine to defend Eppen (1979) establishes the square-root pooling result; the magnitude here is my scenario input, labeled as such on the demo page Hide how each was checked GOVERNANCE ✓ Synthetic data only: a fictional manufacturer, invented item numbers and quantities, no real company or client referenced ✓ The pooling direction is a published result; the magnitude is a labeled scenario input, the number I would want challenged first ✓ Every named statistical method cites a primary source that opens live ✓ The classification, the policy, the buffer zones, and the net-flow status all compute from the raw inputs, so nothing is hand-tuned WHAT TRANSFERS Method selected from the literature rather than habit, cited so it can be checked, computed rather than asserted, and my own softest assumption labeled as such. That is what I would bring to a planning review, and it is the reason I can build this without touching anyone's data. STACK DDMRP buffer model Syntetos-Boylan-Croston demand classification Self-contained static page No backend Open the interactive demo If you build or hire around systems like this, say hello. julia@jbroberg.com ← All systems --- ## The specification is the system URL: https://jbroberg.com/work/ai-exec-team Part of one argument: agents propose, a human decides, the record survives. AGENT ORG DESIGN The specification is the system A written operating standard for deploying AI agents: one job per seat, a published evidence base behind every recommendation, an audition before anything is trusted, and a human holding every decision. Designed against the research on why these systems actually fail. Read the full specification Owner Decision gate Ops and SC Analyticalseats Advisory seats Specialist seats sit under a single decision gate; recommendations rise to the owner, who decides and signs, and every ruling is logged. 42% of multi-agent failures trace to specification, not the model WHY IT MATTERS Eleven seats specified, three written to audition standard. Building the rest earlier would be theater. Most multi-agent systems fail on specification, not model quality, so I write the governance first and let the org chart follow. A specification, not a running fleet. SPECIFIED PROBLEM Organizations deploying AI agents assume the risk is model quality. The research says otherwise. Across more than 1,600 execution traces from seven multi-agent frameworks, roughly 42% of failures traced to specification and system design: vague roles, undefined completion criteria, unchecked authority. Not a model problem. A management problem, and one that better models will not fix. The implication for anyone deploying this in an operating company: the design document is the control. So I wrote mine, publicly, before building. WHAT IT DOES The design is a standard, not a running fleet, and its worked example is the seat that maps to the job I want: planning and inventory. That seat has one job. Every planning, inventory, or MRP analysis selects the best published statistical model for the observed demand pattern, cites it, recalculates, and states its limits. Never a naive average. Evidence base: demand classified by ADI and CV squared decides the model. Croston's method for intermittent items, the Syntetos-Boylan approximation correcting its bias, TSB where obsolescence risk matters, and the M5 findings on tree-based methods at higher aggregation levels. DDMRP policy bands translate the output into a decision. Audition: fed a dataset with known answers, it must classify the SKUs, pick per-class models with citations, and flag the series where a simple average would have been badly wrong. If it misses that series, it is not used. That is the difference between an AI that produces a forecast and one that produces a forecast someone can defend in a planning review. Eleven seats are specified. Three are written to audition standard. The rest ship only when the inputs exist to make them real, and some may never ship at all. A seat that cannot pass its audition does not get hired, same as a person. OUTCOMES - EVERY CLAIM GRADED Every claim here is either verified against an artifact I can show you, or marked as my own report. Ask for either. VERIFIED Every seat maps to a documented, published framework, and every cited source opens live the sources listed in the specification open live; verified 2026-07-20 VERIFIED Ships as a self-contained static page, no external calls, rendered clean under production CSP served at /demos/ai-exec-team/ in the site build; loaded in a headless browser under the production CSP with zero console errors, 2026-07-18 REPORTED A specification, not a running fleet. Nothing is deployed and each seat ships only after passing a written audition the specification's rollout and standing-law sections state the gate; no agent in the fleet is deployed Hide how each was checked GOVERNANCE ✓ Recommend, never decide: rulings land in a decision log and a named human signs ✓ Grounding for facts, judgment for framing: analytical seats search, cite, and recalculate, and no seat invents a number ✓ No claim ships beyond what the record supports; a missing fact is escalated, not guessed ✓ Audition before trust: no seat is used until it passes a written test against cases with known answers ✓ One job per seat, with a written definition of done ✓ Strict separation: no confidential material from any outside obligation enters a knowledge pack WHAT TRANSFERS I write the governance before the code, I source the reasoning to published work rather than opinion, and I mark what I have verified separately from what I am asserting. Applied here to an agent fleet. Applied at work to forecasts, supplier decisions, and planning policy, where being wrong costs inventory rather than embarrassment. STACK Multi-agent design Orchestrator-workers pattern Evaluator-optimizer loop Evidence-based knowledge packs Human-in-the-loop governance Static HTML blueprint Read the full specification If you build or hire around systems like this, say hello. julia@jbroberg.com ← All systems Specialist seats under one human decision gate --- ## Multi-site planning demo URL: https://jbroberg.com/demos/planning/ SYNTHETIC DEMO Halden Forgeworks is a fictional company. Every figure here is an invented scenario input, not a claim about any real business. Skip to main content THE SCENARIO One company, three plants that don't talk Halden Forgeworks makes cast-iron cookware and outdoor cooking gear. It grew by acquisition, so its three plants run three planning worlds - different systems, separate spreadsheets, no shared picture. Two of them buy the same long-lead brass valve from the same overseas supplier, and neither can see the other's orders. Every order each plant places is a bet on what the other one just did. MADE UP ON PURPOSE Halden Forgeworks is invented - the company, its plants, its item numbers, and every quantity here. Nothing on this page comes from a real employer, client, or dataset. What is real is the problem: this is the pattern I have spent years inside, rebuilt from scratch so the method can be shown without anyone's data in it. HM Halden Main The original foundry. Casts and enamels the core cookware line. Runs the oldest ERP of the three. LEGACY ERP CB Cutter Bay Assembly Builds camp stoves and accessories. Acquired two years ago, still plans in its own spreadsheet. RECENT ACQUISITION RF Rooksford Finishing Finishing, engraving, and pack-out. Handles seasonal and custom work that spikes and then goes quiet. LUMPY DEMAND THE COORDINATION PROBLEM The shared valve, planned two ways Item BV-38, a brass burner valve, feeds camp stoves at Cutter Bay and range-top kits at Halden Main, eight weeks from a shared supplier. Planned as two islands, each plant carries its own cushion against the same risk and can't see the other's orders. Here's where the story turns: if their bad weeks don't usually land together, how much of that doubled cushion is protection - and how much is hope with a carrying cost? Flip the switch and watch it move. PLAN THE VALVE AS Two islands One network buffer Cutter Bay BV-38 / CB 0 top of red 409 reorder 1,289 max 1,553 Halden Main BV-38 / HM 0 top of red 260 reorder 820 max 1,020 Two islands 2,574 COMBINED STOCK TARGET 670 COMBINED SAFETY CARRIED 1 PLANTS BELOW SAFETY Switch to one network buffer and this scenario moves: plants below safety 1 -> 0, combined stock target down 76, safety carried down 44 - here's where that comes from, in the note below. Each island sizes its own buffer against the same eight-week supplier, blind to the other's orders. Look at the two bars: Cutter Bay's net flow has already fallen below its safety line while Halden Main sits on cover it can't lend - more total stock than one shared buffer would carry, and a plant still heading for a stockout. The supplier reads two jumpy signals instead of one. That's planning on hope, priced. What the pooling number means What is published: pooling independent demand reduces required safety stock, with the benefit scaling as the square root of the number of locations (Eppen 1979). The result weakens as site demands become positively correlated, and later work established that it depends on the light-tailed nature of the demand distribution. What is my scenario input: the variability factors here, 0.55 per island against 0.45 pooled, encode partial correlation between the two plants. Price the network at the islands' own 0.55 and the safety saving goes to zero. The direction is established; the magnitude is mine, and it is the number I would want challenged first in a real review. A note on the boundary: Kostenko and Hyndman (2006) showed the classification boundary should be non-linear rather than four rectangular cells; the original authors accepted the revision while defending theirs as the more practical scheme. POLICY BANDS Policy replaces hope Not every item deserves the same treatment, and no planner should have to hope their way through the whole board every Monday. Each item carries a demand signature - how often it actually sells, and how much a sale jumps around when it does. That signature, plus volume and lead time, decides which of five policy bands it lands in: what the system does on its own, and what stays with a human. Pick a band to filter, or open any item and it shows its work. Halden is made up - the problem and the method are not: every policy, demand class, and buffer zone on this board is computed live from the scenario inputs - change a number and everything recalculates. Only the item and site labels and the scenario inputs themselves are typed in. Standing auto-ship Sells steadily at high volume - the smooth class 2 items Banded min-max, weekly review Sale sizes swing hard - the erratic class 2 items Partial standing Steady but mid or low volume - still smooth 3 items Order-driven Quiet stretches, jumpy sizes - intermittent or lumpy 3 items Flagged for review Nothing usable to read yet - no class assigned 1 item HF-DUTCH-6Q 6 qt enameled Dutch oven STANDING AUTO-SHIP Halden Main IN THE GREEN PIG-G3 Foundry pig iron, grade 3 STANDING AUTO-SHIP Halden Main + Cutter Bay (shared) IN THE GREEN HF-SKILLET-12 12 in cast skillet BANDED MIN-MAX, WEEKLY REVIEW Halden Main BELOW MIN BV-38 Brass burner valve, 3/8 NPT BANDED MIN-MAX, WEEKLY REVIEW Cutter Bay + Halden Main (shared) REORDER NOW CB-STOVE-2B 2 burner camp stove PARTIAL STANDING Cutter Bay REORDER NOW EFR-BLU Enamel frit, cobalt blue PARTIAL STANDING Halden Main + Rooksford (shared) REORDER NOW HF-TRIVET-CI Cast trivet PARTIAL STANDING Halden Main REORDER NOW CB-GRIDDLE Cast griddle plate ORDER-DRIVEN Cutter Bay BELOW MIN RF-GIFT-SET Holiday gift set ORDER-DRIVEN Rooksford BELOW MIN RF-ENGRAVE Custom engraved lid, made to order ORDER-DRIVEN Rooksford BELOW MIN CB-WINDSCR Stove windscreen kit (new SKU) FLAGGED FOR REVIEW Cutter Bay UNMAPPED CB-WINDSCR Stove windscreen kit (new SKU) Finished good · Cutter Bay FLAGGED FOR REVIEW Close - AVG USAGE / WK No history DEMAND CLASS 4 wk LEAD TIME It's a brand-new SKU with no sales to read and no buffer profile assigned, so the system refuses to guess a policy. POLICY The item has no demand history or no buffer profile yet, so the system will not guess. It goes to a planner to classify by hand before it gets a policy. No buffer No demand history yet, so no buffer is calculated. A planner classifies it by hand before it earns a policy. HOW THE BANDS ARE DECIDED The method is public, and it isn't one average The bands aren't a house opinion. They ride on two published ideas: a demand-classification scheme that sorts items by pattern, and demand-driven buffers that hold stock in colored zones and reorder off a net-flow signal. The demand signature Two numbers describe how an item sells. ADI, the average demand interval, counts how many periods pass between sales. CV squared, the squared coefficient of variation, measures how much the size of a nonzero sale jumps around. The Syntetos-Boylan-Croston scheme splits items into smooth, erratic, intermittent, and lumpy at cutoffs of ADI 1.32 and CV^2 0.49. A smooth, steady item can stand on a buffer. A lumpy, once-a-quarter item can't, and pretending otherwise buries cash in stock that rarely moves. The buffer, not a reorder point Demand Driven MRP holds stock in three zones: a red safety base, a yellow coverage band, and a green reorder band. The net flow position is on-hand plus what's already on order minus qualified demand (confirmed orders and near-term spikes, not a forecast). When net flow falls into yellow, you order back up to the top of green. Zone sizes come from average usage, the decoupled lead time (the wait the buffer actually has to cover), and two factors for lead time and variability, so a long-lead volatile part carries more safety than a short-lead steady one. Average usage itself can be read from the past, the forecast, or a blend, so no single naive mean has to carry the whole plan. WHAT THIS DEMO IS, AND ISN'T This is a working illustration of a planning method on invented data. It is not a live system, not a connected planner, and not a claim that any real operation runs these numbers. Every quantity is a scenario input chosen to make the method legible in two minutes. Where a statistical method is named, it links to a public source below. Where the demo makes a softer point, such as pooling safety across sites, it says so in plain terms rather than dressing a rule of thumb up as a proof. SOURCES, VERIFIED LIVE Demand classification cutoffs (ADI 1.32, CV squared 0.49) and the smooth, erratic, intermittent, and lumpy classes. Syntetos, Boylan and Croston (2005), "On the Categorization of Demand Patterns," Journal of the Operational Research Society 56, 495-503. scirp.org/reference/referencespapers?referenceid=1695888 Croston bias and the Syntetos-Boylan approximation. Syntetos and Boylan (2005), "The accuracy of intermittent demand estimates," International Journal of Forecasting. Pooling reduces required safety stock (the square-root law). Eppen (1979), "Effects of Centralization on Expected Costs in a Multi-Location Newsboy Problem," Management Science 25(5), 498-501. semanticscholar.org/paper/Note-Effects-of-Centralization-on-Expected-Costs-Eppen DDMRP buffer zones and net flow. Ptak and Smith, Demand Driven Material Requirements Planning (primary reference). Secondary, how this appears in an ERP: Microsoft Learn, Dynamics 365 Supply Chain Management. learn.microsoft.com/en-us/dynamics365/supply-chain/master-planning/planning-optimization/ddmrp-buffer-profile-and-levels Plain-English explainer (secondary). Open Forecast, Ivan Svetunkov. openforecast.org/2024/07/16/intermittent-demand-classifications-is-that-what-you-need The same method, at real scale At real scale this runs across every plant and every planned item, on live ERP data instead of invented numbers, with the same logic: classify each item by its own demand, buffer off net flow, and pool the shared components. The demo is the method with the stakes removed. How I set inventory policy across sites · julia@jbroberg.com --- ## The AI executive team - org blueprint URL: https://jbroberg.com/demos/ai-exec-team/ JB // ORG DESIGN // THE AI EXECUTIVE TEAM The AI executive team - org blueprint A mini company of expert agents, each built on a documented, evidence-backed framework. I own every decision. The orchestrator dispatches and verifies. Specialists recommend - they never decide, never invent numbers, and never emit a claim the public record does not support. DWG. JB-ORG-AI-EXEC-TEAM | REV. A | OWNER. JULIA | DATE. 2026-07-17 | STATUS. SPECIFIED Formatted as a controlled engineering drawing, because a specification with no revision, owner, or status is not a specification. THE PROBLEM THE DESIGN SOLVES Organizations deploying AI agents assume the risk is model quality. The research says otherwise. Across more than 1,600 execution traces from seven multi-agent frameworks, roughly 42% of failures traced to specification and system design: vague roles, undefined completion criteria, unchecked authority. Not a model problem. A management problem, and one that better models will not fix. The design document is the control, so here is mine. Cemri et al., Why Do Multi-Agent LLM Systems Fail, NeurIPS 2025. STANDING LAW FOR EVERY SEAT Recommend, never decide. Rulings land in a decision log and a named human signs. Grounding for facts, judgment for framing. Analytical seats search, cite, and recalculate. No seat invents a number. No claim ships beyond what the record supports. A missing fact is escalated, not guessed. Audition before trust. No seat is used until it passes a written test against cases with known answers. One job per seat with a written definition of done. Strict separation. No confidential material from any outside obligation enters a knowledge pack. GOVERNANCE FIRST - WHO DECIDES I am the CEO here. Not an agent. The evidence base is unambiguous: multi-agent systems fail most often on specification and unchecked authority, and the human-as-final-approver is the pattern every serious builder keeps. My own system law already says it - every proposal is human-submitted, every ruling lands in a decision log. So the top agent seat is reframed: The Chair challenges and frames decisions the way top-performing CEOs behave - it does not hold the pen. The COO seat is already filled: it is an established orchestrator pattern (dispatch one work order, verify against the definition of done, append the baton). Nothing new to invent at the top - the fleet plugs into it. THE ORG CHART Julia CEO - DECIDES, SIGNS, SUBMITS ▾ The Chair DECISION COUNSEL The COO ORCHESTRATOR PATTERN Chief of Staff PERSONAL AGENT - IN DESIGN ▾ Ops & SC Exec PLANNING + MODELS CFO ROI, DCF, NPV First Principles THE ALGORITHM Delegation Coach BUYBACK + FOCUS Client Psychologist LISTEN WITH INTENTION Talent Partner EVIDENCE-BASED HIRING Voice Editor GATES EVERY ARTIFACT Risk Sentinel CONFLICT SCREEN + TERMS Persona note: the challenger and coach seats are built on published management frameworks only - documented methods, not impersonation, no fabricated quotes. Persona voice is for judgment and challenge; anything factual is still grounded and cited. THE ROSTER - EACH SEAT, ITS EVIDENCE, ITS ONE JOB The Chair - CEO-caliber decision counsel PERSONA: JUDGMENT ONE JOB Pressure-test any significant decision and force a recommendation with a named trade-off - then file it to the decision log for my ruling. EVIDENCE BASE The CEO Genome Project (ghSMART, 17,000+ executive assessments, featured in HBR): successful CEOs share four behaviors - deciding with speed and conviction, engaging stakeholders for impact, adapting proactively, delivering reliably. Charisma and pedigree showed little bearing on performance. hbr.org/2017/05/what-sets-successful-ceos-apart KNOWLEDGE PACK The four behaviors as a question protocol ("a wrong decision is often better than no decision - what does waiting cost?"), and the decision log with outcomes. AUDITION Replay past decision-log rulings. It must surface the same trade-offs I saw, and at least one I missed. Senior Executive, Operations & Supply Chain GROUNDING: MANDATORY ONE JOB Every planning, inventory, or MRP analysis uses the best published statistical model for the demand pattern - selected, cited, and recalculated. Never a naive average. EVIDENCE BASE The intermittent-demand literature: Croston's method as the standard for intermittent items, the Syntetos-Boylan Approximation (SBA) correcting its bias, and TSB for obsolescence risk (M5 inventory-performance analysis, Croston/SBA/TSB comparison). Demand classification by ADI and CV² decides which model applies, and M5 competition findings (tree-based methods like LightGBM at higher aggregation levels) round out the toolbox (combining probabilistic intermittent forecasts). KNOWLEDGE PACK Demand-classification quadrants, the model-selection decision tree, DDMRP policy bands (auto-ship / banded min-max / order-driven / flagged), and a documented what-good-looks-like standard. STANDING RULE "Search for the best published model for this pattern, cite the source, recalculate, and state model limits." The loop, made law. AUDITION Feed it the synthetic demo dataset. It must classify the SKUs, pick per-class models with citations, and flag the one series where a simple average would have been badly wrong. The CFO GROUNDING: MANDATORY ONE JOB Every proposed build gets a numbers verdict: ROI in the decision's own currency, and DCF/NPV thinking where cash flows span time. Guards the no-invented-numbers law. EVIDENCE BASE Standard corporate-finance method as taught openly by Aswath Damodaran (NYU Stern, "Dean of Valuation"): DCF built from cash flows, growth, and a matched discount rate - never mix cash flows and discount rates - plus relative valuation as the cross-check (free lecture notes, spreadsheets, and datasets, DCF inputs). Layered with my own ROI law: three return languages (time returned, cost reduced, revenue increased), one standard visual, weak numbers shown. KNOWLEDGE PACK The ROI ledger schema, Damodaran's DCF templates, and the honest-ledger doctrine: weak numbers shown, never hidden. AUDITION Hand it three ledger rows including a weak one. It must defend the weak number's presence, not hide it - and refuse to fill a [CONFIRM] with a guess. First-Principles Challenger PERSONA: CHALLENGE ONE JOB Attack scope before work starts. Run every build plan and proposal scope through the algorithm, in order, and name what should not exist. EVIDENCE BASE Musk's five-step algorithm, in strict order: question every requirement (each carries a named person, not a department), delete parts and process (if you don't add back 10% you didn't delete enough), simplify and optimize, accelerate cycle time, automate last. The documented failure mode: automating a step that shouldn't exist. Isaacson, Elon Musk (2023), the five-step algorithm; framework analysis. KNOWLEDGE PACK The five steps with the two operational rules, the kill list, and past scope-bloat examples from prior build logs. AUDITION Give it a deliberately padded work order. It must delete at least a third and attach a requirement owner to everything that survives. Delegation Coach PERSONA: ACCOUNTABILITY ONE JOB Sort tasks by money and energy, surface the highest-value delegation, and name the one trade worth making next. EVIDENCE BASE Dan Martell's published Buy Back Your Time system: the Buyback Loop (audit - transfer - fill), the DRIP matrix sorting tasks by money and energy, the buyback rate (delegate anything below roughly a quarter of your effective hourly rate), the replacement ladder for what to hand off first, playbooks so delegation sticks, and the five time assassins - self-sabotage patterns like the Supervisor and the Saver. Martell, Buy Back Your Time (book); buybackyourtime.com. KNOWLEDGE PACK The DRIP matrix and the buyback-rate threshold, the replacement-ladder order, and delegation playbooks so a handoff sticks. AUDITION Give it a sample week of logged tasks. It must call out one Level-1 trade (time for money) and one energy drain - and propose exactly one change, not five. The Client Psychologist PERSONA + TRANSCRIPTS ONE JOB From conversation transcripts: build a communication profile of the counterpart - what they value, what they avoid saying, how they decide - and translate the message into their register. EVIDENCE BASE A listen-with-intention pattern, run twice on every recording (default read, then intentional read: what are they really asking, where do they struggle). Bounded honestly: this agent profiles communication style and stated priorities - it never diagnoses people, and its profiles are hypotheses tested against the next call, not facts. Its value is measured against real call outcomes, not assumed. KNOWLEDGE PACK The three-layer communication doctrine (executive / expert / super-nerd, always re-simplified before the client), call debriefs, and outcome verdicts. AUDITION Replay a past conversation with a known outcome. Its profile must predict the objection that actually came - or it goes back for pack revision. The Talent Partner GROUNDING: MANDATORY ONE JOB When work is delegated: role scorecard, structured interview kit, and a paid test project - nothing handed off on vibes. EVIDENCE BASE The Schmidt & Hunter meta-analysis of 85 years of selection research: structured interviews, work samples, and general mental ability sit at the top of the validity hierarchy; unstructured interviews, years of experience, and credentials sit near the bottom - and combining GMA with a structured interview or work sample yields composite validity around .63 (Schmidt & Oh, 100 years of research, hierarchy incl. the 2022 Sackett update). Martell's test-first hiring is the same finding in operator language: the paid test project is a work sample. KNOWLEDGE PACK Scorecard template, structured question banks scored against anchors, test-project briefs per role, my teach-the-team handoff doctrine. AUDITION Give it one role. It must produce a scorecard plus a scoreable work sample - and refuse to rank candidates on resume polish. The Voice Editor EVALUATOR GATE ONE JOB The evaluator half of an evaluator-optimizer loop: nothing client-facing or going out under my name ships until it passes voice law - short hyphens by codepoint, no AI-tell patterns, contractions in, claims traceable to the public record, no banned words. EVIDENCE BASE The evaluator-optimizer pattern from Anthropic's agent-design guidance: one model generates, another evaluates against explicit criteria, looping until quality is met (Building Effective Agents). The voice rules are the criteria - already written, already binding. KNOWLEDGE PACK The voice and format rules verbatim, and before/after examples of de-AI-fied text in my register. AUDITION Feed it a draft seeded with five known violations. Five out of five caught, or the pack gets fixed. The Risk Sentinel FAIL-CLOSED GATE ONE JOB Runs the conflict screen and platform-rules check on everything outbound: conflict-of-interest exposure and ownership-model consistency. Holds on doubt; I release. EVIDENCE BASE Pattern already validated in a prior build: a three-stage screening gate (conflict, kill, fit) with corpus replay - including deliberately bad inputs - is the audition pattern the agent literature recommends, and an earlier review fleet's pre-commit catch showed why the seat exists. Not a lawyer: anything genuinely legal (employment terms, contracts) gets flagged to me for professional review, never resolved by the agent. KNOWLEDGE PACK The conflict screen verbatim, the kill list, the ownership model, the platform-terms constraint, and the near-miss log. AUDITION The validation run behind that: corpus-replay findings ruled, false positives released, hard rejects confirmed. Re-run on every rule change. ROLLOUT - THREE PHASES, ONE SEAT AT A TIME PHASE 1 - EARN THEIR KEEP NOW Ops & SC Exec, CFO, Voice Editor Ops Exec powers the planning demo's model honesty. CFO hardens the ROI ledger. Voice Editor gates both. Risk Sentinel already exists as a screening gate - formalize its pack, don't rebuild it. PHASE 2 - AFTER THE GROUNDWORK Chief of Staff, Chair, Coach, First Principles The Chief of Staff is the specced personal agent, still in design. The Chair, Coach, and Challenger draw on it, so they follow, not lead. PHASE 3 - WHEN THE INPUTS EXIST Client Psychologist, Talent Partner The Psychologist needs real call recordings and outcomes to learn from. The Talent Partner activates when there's an actual hire or delegation to make. Building them earlier is theater. Why phased: a strong single agent often beats a sprawling team. Every seat here ships only when it passes its audition - an expert that can't pass its audition isn't hired, same as a person. SOURCES CEO Genome Project / What Sets Successful CEOs Apart (HBR, ghSMART): hbr.org/2017/05/what-sets-successful-ceos-apart and ceogenome.com/about Musk's five-step algorithm: Isaacson, Elon Musk (2023), framework analysis Dan Martell, Buy Back Your Time (Buyback Loop, DRIP, replacement ladder), book: buybackyourtime.com Damodaran (NYU Stern) open valuation resources - DCF, WACC, datasets: pages.stern.nyu.edu/~adamodar Intermittent demand: Croston / SBA / TSB and M5 evidence: ScienceDirect M5 inventory study, arXiv probabilistic combination Schmidt & Hunter selection validity (structured interviews, work samples, GMA): Schmidt & Oh working paper, hierarchy + 2022 update Agent patterns (orchestrator-workers, evaluator-optimizer, subagents) and persona-prompting grounding: anthropic.com/research/building-effective-agents MAST failure taxonomy (~42% specification failures): Cemri et al., Why Do Multi-Agent LLM Systems Fail, NeurIPS 2025, arxiv.org/pdf/2503.13657, orq.ai analysis I HOLD THE PEN / EVERY SEAT AUDITIONS BEFORE IT'S HIRED / GROUNDING FOR FACTS, PERSONA FOR JUDGMENT / ONE SEAT AT A TIME BACK TO THE CASE STUDY --- ## Vendor Brain URL: https://jbroberg.com/demos/vendor-brain/ SYNTHETIC DEMO Vendor Brain runs entirely on invented vendors, sites and account numbers. Full disclaimer below. COLOR SCHEME Dark editorial Operations journal Skip to main content THE PROBLEM One supplier, four account numbers A global manufacturer runs several separate ERP systems across its sites. The same real-world supplier shows up as a different vendor account number in each one, so spend cannot be rolled up per supplier, and nobody can answer a simple question: how much do we actually spend with this vendor, across every site, combined. Vendor Brain answers it by reconciling the accounts into one record per real vendor. Riverton Atlas AX Shares its ERP instance with Halden, separated only by a company-code column. Halden Atlas AX Same physical database as Riverton. One system, two company codes, still two sets of vendor accounts. Kobe Sage-90 K Its own standalone Sage-90 instance, with its own numbering scheme for vendor accounts. Turin Sage-90 T A separate Sage-90 instance again - same product family, unrelated account numbers. Lyon Sage-90 L A fourth, independent instance. Four systems in total, none of them aware of the others. HOW IT WORKS Normalize, block, score, cluster, resolve Five steps turn 9,214 raw accounts into 7,980 golden records. The first four are mechanical; the last one is where a person steps in. 01 Normalize Strip legal suffixes, punctuation and case; fold whitespace, so raw names become comparable strings. -> 02 Block Group accounts into candidate sets by cheap keys - first token, site, ERP - so scoring never compares every account to every other one. -> 03 Score Compute a name-similarity score from 0 to 1 for each candidate pair inside a block. -> 04 Cluster (union-find) Union every pair scoring at or above the auto-merge floor; the structure chains multi-hop matches into one connected set. -> 05 Golden records Each connected set collapses to one canonical vendor. Borderline scores route to a human review queue instead of merging blind. THE THRESHOLD CONTROL Where the line falls between a match and a miss A score of 1.00 means exact after normalize, and 0.92 and above always auto-merges - those are not up for debate. Below that, this single control decides how much gets pulled into human review versus written off as a separate vendor. Move it and watch the golden records table below react live. REVIEW THRESHOLD 0.85 0.75 - wider net 0.92 - narrower net Candidates scoring at or above this line but below 0.92 go to the review queue. Below the line, they are treated as separate vendors and dropped from the count. Try lowering it to 0.83 or below - a real near-duplicate, "Calderon Sci.", is sitting just under the default line, which is the illustrative edge case this control exists to show. 10 auto-merge 2 review 1 separate Reset threshold and reviewer decisions Review queue 2 awaiting a decision Bright water Reagents Ltd candidate match for Brightwater Reagents · Turin / Sage-90 T / 3092210 · similarity 0.90 Merge Keep separate Aldergrove Bio candidate match for Aldergrove Biosystems · Lyon / Sage-90 L / 3141002 · similarity 0.88 Merge Keep separate THE GOLDEN RECORDS Ten suppliers, reconciled from twenty-four raw accounts Every row below is a canonical vendor. Open one to see the source accounts that fed it - the site, the ERP, the raw account number, the raw name as it was entered, and the similarity score that decided its fate. This table reads the same threshold and reviewer decisions as the control above. GOLDEN RECORD SOURCE ACCOUNTS SITES ERPS STATUS Meridian Labworks 4 4 3 4 AUTO SITE ERP ACCOUNT # RAW NAME SIMILARITY STATUS Riverton Atlas AX V-004821 Meridian Labworks Inc 1.00 EXACT Halden Atlas AX V-119027 Meridian Lab Works 0.97 AUTO-MERGE Kobe Sage-90 K 3021145 MERIDIAN LABWORKS, LLC 0.94 AUTO-MERGE Turin Sage-90 T 3098412 Meridian Labworks (Reagents) 0.93 AUTO-MERGE Calderon Scientific 3 3 2 2 AUTO 1 SEPARATE SITE ERP ACCOUNT # RAW NAME SIMILARITY STATUS Riverton Atlas AX V-002310 Calderon Scientific Corp 1.00 EXACT Halden Atlas AX V-087713 Calderon Scientific Corporation 0.98 AUTO-MERGE Kobe Sage-90 K 3011882 Calderon Sci. 0.83 SEPARATE Nordvik Instruments 2 2 1 2 AUTO SITE ERP ACCOUNT # RAW NAME SIMILARITY STATUS Halden Atlas AX V-090114 Nordvik Instruments AB 1.00 EXACT Riverton Atlas AX V-005567 Nordvik Instrument 0.96 AUTO-MERGE Brightwater Reagents 2 2 2 1 AUTO 1 REVIEW SITE ERP ACCOUNT # RAW NAME SIMILARITY STATUS Lyon Sage-90 L 3140228 Brightwater Reagents 1.00 EXACT Turin Sage-90 T 3092210 Bright water Reagents Ltd 0.90 REVIEW Aldergrove Biosystems 3 3 3 2 AUTO 1 REVIEW SITE ERP ACCOUNT # RAW NAME SIMILARITY STATUS Riverton Atlas AX V-003398 Aldergrove Biosystems Inc 1.00 EXACT Kobe Sage-90 K 3025519 Aldergrove BioSystems 0.98 AUTO-MERGE Lyon Sage-90 L 3141002 Aldergrove Bio 0.88 REVIEW Sundberg Glassware 2 2 2 2 AUTO SITE ERP ACCOUNT # RAW NAME SIMILARITY STATUS Halden Atlas AX V-101245 Sundberg Glassware Co 1.00 EXACT Turin Sage-90 T 3090781 Sundberg Glass Ware 0.95 AUTO-MERGE Tanaka Precision Optics 2 1 1 2 AUTO SITE ERP ACCOUNT # RAW NAME SIMILARITY STATUS Kobe Sage-90 K 3020034 Tanaka Precision Optics 1.00 EXACT Kobe Sage-90 K 3027781 Tanaka Precision Optics KK 0.97 AUTO-MERGE Castellane Chemicals 3 3 3 3 AUTO SITE ERP ACCOUNT # RAW NAME SIMILARITY STATUS Lyon Sage-90 L 3139004 Castellane Chemicals SA 1.00 EXACT Turin Sage-90 T 3091660 Castellane Chemical 0.96 AUTO-MERGE Riverton Atlas AX V-006612 Castellane Chemicals 0.99 AUTO-MERGE Whitfield Filtration 2 2 1 2 AUTO SITE ERP ACCOUNT # RAW NAME SIMILARITY STATUS Riverton Atlas AX V-004003 Whitfield Filtration LLC 1.00 EXACT Halden Atlas AX V-118890 Whitfield Filtration 1.00 EXACT Pemberton Plastics 1 1 1 1 AUTO NO DUPLICATES SITE ERP ACCOUNT # RAW NAME SIMILARITY STATUS Turin Sage-90 T 3093347 Pemberton Plastics Inc 1.00 EXACT Flagged intercompany accounts (excluded from external spend) Riverton Atlas AX V-000255A Internal - Riverton Plant Transfer Kobe Sage-90 K 3005385 Internal - Kobe Intercompany WHAT THE SCORE ACTUALLY MEASURES A score is a lead, not a verdict Two ideas do the real work here: cutting the comparison space down before scoring, and letting the same threshold logic run everywhere on the page instead of being hand-tuned per screen. Blocking before scoring Comparing every account to every other account does not scale - 9,214 accounts is over 42 million possible pairs. Block groups accounts by a cheap shared key first, so Score only ever runs inside a small candidate set, not the whole table. This demo shows the aliases already grouped under their golden record for clarity. In production, blocking is the step that finds those groups in the first place. One threshold, everywhere The slider above, the review queue, and every chip in the golden records table all read the same classifyAlias function and the same state. Move the threshold once, and every view updates together - there is no second copy of the rule to drift out of sync. A reviewer's merge or keep-separate decision is stored as an override on that one alias, so it survives further threshold changes until it is undone. WHAT THIS DEMO IS, AND ISN'T This is a working illustration of a record-linkage method on invented data. It is not a live system, not connected to any real ERP, and not a claim that any real operation holds exactly these numbers. Every account, name and score is a scenario input chosen to make the method legible in a couple of minutes. The headline totals in the stat row (9,214 accounts down to 7,980 golden records) are a fixed, invented scenario figure, separate from the ten illustrative golden records shown in the table, which are small enough to read in full. ---