Kevin Raad · CI Strategy Engineer

Montréal, Québec | Beirut, Lebanon

Kevin
Raad,

a CI Strategy Engineer

I build the models and the software that guide operating decisions.

Operations research applied to a manufacturing plant, and then shipped. Stochastic optimisation, scheduling theory and forecasting, delivered as the systems that plan and schedule production rather than as reports.

Montréal, QC LinkedIn ↗
7
projects taken from problem definition through to deployed system
5
in daily production use; one in testing, one in development
5
plant departments served: planning, maintenance, production, quality, floor supervision
03

LinkedIn

Profile, background and contact.

Open in a new tab

Methods

Models and techniques used

Each of these was chosen against alternatives that were built and rejected, and each carries a specific test that would have exposed it as wrong.

Stochastic optimisation
Newsvendor model

Sizing a standing crew against random daily shortage, the cost of an idle employee against the premium of covering a gap at overtime rates. Solved by direct convex minimisation rather than the critical-ratio shortcut, which does not hold when one crew spans several overtime rates.

Certified by: Backtested on held-out shifts, then reconciled against an independent payroll export
Scheduling theory
Parallel machines, sequence-dependent setup

An NP-hard scheduling problem with deadlines, machine eligibility, downtime and a lexicographic objective. Solved by a deterministic constructive heuristic, earliest-deadline placement, a Moore-Hodgson-style repair pass, priority redistribution, then a right-shift that recovers freshness without creating a new miss.

Certified by: Certified against a combinatorial lower bound; sits on it exactly
Constraint programming
CP-SAT: built and rejected

A full constraint model of the same problem produced the best raw schedules and was rejected as non-deterministic: under a wall-clock limit it returned wildly different answers on near-identical input. A tool acted on every half hour cannot change its mind.

Certified by: Rejection documented with the run-to-run variance that caused it
Forecasting
Model competition + Monte Carlo

Rather than choose a forecasting method, nine run in competition and are scored per production line by rolling validation with no look-ahead. The winner generates prediction intervals from a 10,000-sample simulation. A separate back-test measures how often the winner changes, turning method instability into a re-evaluation cadence.

Certified by: Selection by out-of-sample RMSE, never in-sample fit
Algorithms
Interval-union sweep

Overlapping events were being summed independently, so concurrent stoppages double-counted. Replaced with an exact union of intervals on a shared absolute timeline, which also handles a window crossing midnight without special-casing.

Certified by: Validated against brute force over 60,000 randomised cases
Simulation
Discrete-event modelling

Current-state and future-state models tracking material through the process, run over a window long enough to follow the last batch of a day to its outcome rather than stopping when the schedule does.

Certified by: Used to validate the scheduling logic before deployment
Statistics
Bootstrap resampling

Each decision was re-solved against thousands of resamples of its own input to report how often the same answer returns, then the sensitivity of cost to being off by one was measured, so an unstable decision could be shown not to matter.

Certified by: Instability measured, then shown to be immaterial
Data engineering
Parsing and reconciliation pipelines

Twenty months of operational history recovered from weekly spreadsheets by a purpose-built parser, and a six-figure-row payroll export rebuilt from a malformed single-column file, then each used to check the other rather than trusted on its own.

Certified by: A silent parser bug halving the demand signal was caught this way
Kevin Raad · Montréal

Curriculum vitae

One page. The method behind each role lives in the portfolio.

KEVIN RAAD

kvnraad@gmail.com  |  +1 (514) 452-6444  |  Montreal, Canada  |  linkedin.com/in/kevin-raad
Profile

Industrial engineer (B.Eng., Concordia) who takes operations problems from definition to deployed software. On contract with Keurig Dr Pepper's Montreal coffee plant, where seven projects now run production planning, scheduling, reporting and quality analysis for four departments. Builds the model and ships the system: operations research in Python, delivery on the Microsoft Power Platform. Trilingual, with earlier industrial experience in the energy sector in Italy and the UAE.

Education
B.Eng. Industrial Engineering (CEAB-Accredited) | Concordia University, Montreal, Canada
2021/09 – 2026/05
Baccalaureate in General Sciences (French) | College Notre Dame de Jamhour, Lebanon
2021/06
Professional experience
Continuous Improvement Strategy Specialist (Contract) | Keurig Dr Pepper, Montreal, QC
2026/05 – Present
  • Delivered a relief-staffing optimisation model, a newsvendor formulation solved on historical shift data and validated against an independent system of record. Approved and named the highest-value project of the Q3 productivity summit.
  • Designed a deterministic scheduling engine that recovers production time, solving a parallel-machine problem with deadlines, machine eligibility and sequence-dependent setup. Certified against a combinatorial lower bound, which it reaches exactly.
  • Built a quality non-conformity analysis delivered as generated HTML reporting with a detector that raises hypercare alerts on recurring patterns, scoped in a three-day Kaizen with CI, quality, maintenance and production; and a breakdown workflow that automates the escalation chain and timestamps every action against a person and a line.
  • Automated four processes previously run on spreadsheets, whiteboards and verbal handover, including three reports assembled by hand every shift, delivering Power Platform applications and Python services writing to SQL Server.
  • Worked directly with planning, maintenance, production, quality and floor supervision to define requirements, validate models on real operating data and run acceptance testing with end users.
  • Established the verification practice behind the work: algorithms checked against brute force, decisions stress-tested by resampling, and models reconciled against independent systems of record.
Capstone Project: Predictive Efficiency & Scheduling | Concordia × Keurig Dr Pepper
2025/09 – 2026/04
  • Built a forecasting model that runs nine methods in competition and picks the winner per production line by out-of-sample rolling validation, with prediction intervals from Monte Carlo simulation.
  • Developed a just-in-time scheduling tool that consumes the forecast through a single-quantity interface, deployed in Power BI with an operator-facing dashboard.
  • Validated both against a discrete-event simulation of current and future state, and audited the written report against the deployed code.
Teaching Assistant – Manufacturing Engineering | Concordia University, Montreal, QC
2025/05 – 2026/04
  • Supported students in CNC programming, machining, sheet metal work and welding; graded process sheets, drawings and inspection reports against manufacturing standards.
Internship – Project & Operations Engineering | Ansaldo Energia S.p.A. Genoa, Italy
2024/07 – 2024/08
  • Followed the full product lifecycle for industrial gas turbines, shadowing a senior project manager through a C-Inspection of a GT36 turbine and building project coordination and structured technical reporting skills.
Internship – Operations & Data Analysis | Ansaldo Energia S.p.A. Abu Dhabi Branch, UAE
2023/05 – 2023/08
  • Ran client-facing operational analysis and reporting for turbine blade repair operations, and took part in the 2023 World Utilities Congress. Delivered in English and Arabic.
Skills
  • Technical: Python (pandas, NumPy, PuLP, OR-Tools), SQL, VBA, C++, Power Apps, Power Automate, Power BI, SharePoint, Office Scripts, SAP, AutoCAD, SolidWorks, Arena, MS Office.
  • Methods: Stochastic optimisation, scheduling theory, constraint programming, forecasting and model selection, Monte Carlo and discrete-event simulation, bootstrap resampling, ETL pipelines, Lean manufacturing, SPC.
  • Languages: English (fluent), French (fluent), Arabic (fluent).
Extracurricular

Lebanese Red Cross Volunteer (2018–2019)  |  7× National Track & Field Champion, represented Lebanon at the U-19 West Asian Championship (2019)  |  Lebanese National Basketball Champions, Jamhour Club (2018–2019).

Kevin Raad · Montréal

Project portfolio

Design to Value. Every case runs through the same four phases: what the baseline actually cost, which options were built and rejected, how the chosen design was engineered and validated, and what the business committed to.

Verified Projected Not measured
Scope

Design to Value normally means product cost engineering: teardown, cleansheet, material substitution, part consolidation, retooling. These seven cases are a different branch of the same discipline, where the cost being designed out sits in process and labour rather than in a bill of materials, and the lever is a decision model rather than a mould. There are no FEA or CFD plots, no competitor teardowns and no margin bridge charts here, because no such work was done; where a phase has no artifact it says so rather than substituting a weaker one.

Data conventions

This version carries no financial results. Savings, returns and cost reductions are described in direction and mechanism rather than in figures, and no currency value appears anywhere. Wage rates, headcounts, machine counts and site identifiers are withheld. Validation counts, sample sizes and engineering specifications are given as run, since they carry the technical argument and disclose nothing about operating economics. The figures exist and are available on request.

How to read the grades

Verified means the result is reproducible from data that already existed, with an independent check against a separate system of record. Projected means it is modelled from a stated baseline. Not measured means the system works and its value has not been quantified. That is the honest default, and it appears here more often than either of the others.

Phase 1
Baseline and insight

What the current state costs and why, derived rather than asserted.

Medium
Phase 2
Options and rejection

What else was built, and the specific property that disqualified it.

High
Phase 3
Technical execution

The chosen design in enough detail to be challenged, and how it was validated.

Very high
Phase 4
Impact and scaling

What the business committed to, and what it returns.

Low
Phase 1
Baseline and insight
Medium

No usable demand series existed, so one was reconstructed: twenty months of shift history, parsed out of the plant's weekly operating workbooks by a purpose-built reader. Shortage per shift was defined as the sum of four absence categories. Whether to include long-term absence was not assumed either way; both definitions were tested against payroll, and only the inclusive one reconciled.

The cost structure that emerged is the insight. Premium-rate coverage outweighs direct crew wages by roughly three to one. The baseline is not a staffing cost with some overtime attached, it is an overtime cost with some staffing attached.

The reframing: absence is modelled as exogenous demand, but it is partly a response to the coverage system itself. A missed shift reliably creates a premium-rate opening, which gives colleagues a standing financial interest in those openings existing. Sizing a crew against that demand risks sizing it against a problem the incentive structure helps produce.

Phase 2
Options and rejection
High

Four structural options were priced against the same twenty months rather than argued in the abstract: status quo at full premium coverage, a permanent crew sized to peak, a permanent crew plus seasonal contract, and single-wave against phased hiring. Sizing to peak was rejected on the summer profile, since it leaves the crew idle most of the year and idle time recovers only a fraction of its wage. The split structure was retained because the demand series is bimodal.

The method rejection that mattered. The textbook newsvendor shortcut computes a critical ratio and reads the answer off the demand distribution. It was built first and discarded, because it assumes a single overstock-to-understock cost ratio and the real structure has several: one crew spans weekdays carrying different premium multipliers, so no single ratio exists. The replacement is direct minimisation across candidate crew sizes, defensible only because the cost function is piecewise-linear with monotone slopes and therefore convex, so a single scan provably returns the global optimum. The shortcut was not wrong so much as inapplicable.

An accounting option that moved the answer. Benefits could be loaded as one flat percentage or split. Splitting was chosen after testing both: the fixed tranche is a charge on base salary and does not move when someone works additional hours, while only the variable tranche rides every dollar paid. That makes a premium hour cost materially less than a flat load implies, shifting the hire-versus-cover trade in a direction a flat assumption would have hidden.

Phase 3
Technical execution
Very high

Cost for a crew carrying n relief against D missing:

Cost(n) = n × wage − salvage × MAX(0, n−D) + premium_rate × MAX(0, D−n)

Try it: where does the crew size land?

Illustrative model. Invented numbers, real structure.

0 5 10 15 20 25 cost crew size
Scan optimum n = 10 Critical ratio n = 8 You are here n = 8
8Relief crew size
7.03Expected cost per shift
1.96Idle crew cost
5.07Premium coverage cost

With two premium rates the critical ratio no longer has a single ratio to use. It reads n = 8 where the true optimum is n = 10, so acting on it leaves money on the table every shift. That is why the model scans instead. The curve is flat around the optimum, which is why being one position out costs almost nothing while being five out costs a great deal.

The salvage term stops an idle employee being modelled as pure loss: idle relief perform non-conforming sorting at a measured rate, displacing contracted labour billed per unit. Carrying it explicitly shifts the optimum upward, so omitting it would have systematically under-hired.

Three modelling decisions, each with a reason. One-time costs stay out of the solver, because training and attrition move the payback date rather than the steady-state optimum; only the seasonal wage discount enters the decision, since a seasonal never reaches full rate. The permanent wage ramp applies to forecasts only, because after two years everyone is at full rate and letting the solver see a temporary discount would over-hire against a rate that expires. Training is modelled as paid-versus-useful rather than as a lump, so every recruit is paid while contributing no coverage and residual premium spend during ramp-up is captured; no separate departure cost is added, which would double-count wages already charged.

Validation. With the correct crew count the model's implied premium-shift count matched what payroll had actually paid, against an independent export rebuilt from a malformed single-column file. The policy was then priced across a held-out window excluded from fitting. Removing the three most extreme days in twenty months moves the recommendation by a single position, and an apparently sensible outlier trim was tested and shown to cost money, because at that threshold it removed ordinary busy days rather than anomalies.

Eight defects were caught before publication, three of which moved the headline materially: a silent parser fault returning zero vacation absence across hundreds of sheets, which understated mean shortage by nearly half with no error raised; two mixed accounting conventions producing a saving inflated by roughly half against the corrected figure; and a premium rate understated because two pay lines were read as alternatives rather than summed.

Phase 4
Impact and scaling
Low

Approved for implementation in September 2026, and the highest-value project presented at the Q3 productivity summit. Year one delivers a reduction against baseline while still absorbing the training cost, and steady state is materially better again once the ramp is complete. The training investment pays back inside the first year, and premium-rate spend falls sharply.

The saving is concentrated rather than even: most of the first year's benefit lands in the summer quarter, and the opening quarter is nearly flat because it carries the first training wave. Both are surfaced rather than smoothed into an annual average, because a plan sold as a large annual number that loses money in its opening quarter will have lost the room by week four.

The second wave is a balancing order, not a commitment. Two live inputs size it: actual survivors from the first wave, and a re-solve against data generated after that wave is working. That matters because of the baseline insight. Between the waves the plant produces several months of absence data under materially reduced premium availability, and if absence falls the optimum falls with it. Three outcomes are defined in advance, including the one where the model turns out to have over-recommended.

Phase 1
Baseline and insight
Medium

Material must rest for a product-specific period after processing before it can be used, then is consumed at a rate that depends on how well the consuming line is running. Schedule late and the line starves; schedule early and the material passes its freshness window and is scrapped. The rest period means every decision is made hours before its outcome is observable, which is why the task had resisted a rule of thumb and was being done by judgement several times a shift.

The baseline is the greedy just-in-time rule that judgement approximates, priced on real data. It is a generous baseline, since it assumes the rule is executed perfectly.

Phase 2
Options and rejection
High

Five engines were built and four rejected, each for a structural reason rather than on score.

Greedy just-in-time is myopic: packing everything to its deadline leaves no earlier idle capacity, so clustered deadlines cascade into each other. Load levelling over-corrects, wasting the freshness window and still missing under contention, which established that pure earliest is as wrong as pure latest.

A CP-SAT constraint model produced the best raw quality of any engine and was rejected anyway, because it is non-deterministic: under a wall-clock limit it returned wildly different answers on near-identical input, since the incumbent at cut-off depends on internal timing. A tool consulted every half hour cannot change its mind. That rejection also closed the obvious hybrid of constructing deterministically then polishing with the solver, because a polish phase reintroduces the drift that disqualified it.

A first deterministic attempt optimised freshness before lateness and so reproduced the greedy weakness exactly. Its failure identified the correct objective ordering, which is what the retained engine is built on.

Phase 3
Technical execution
Very high

A constructive heuristic with no solver and no randomness, following a lexicographic objective directly: never late, then freshness, then setup count, with no lower level improved at the expense of a higher one.

Pack for lateness. Earliest-deadline-first onto the machine that can finish soonest. Any job that cannot meet its deadline on any eligible machine is deferred rather than placed, so a doomed job never occupies capacity a rescuable one needs. This deferral is the single change that separated the retained engine from its predecessor.

Repair. For each still-late job, move it into a free feasible slot, or swap it with an already-doomed job holding a slot inside its window. Every move converts exactly one late job and never creates a new one, so the count strictly decreases and the pass provably terminates.

Priority redistribution. Once the late count is minimal, a late job from a higher-priority line takes the feasible slot of a lower-priority one, which inherits the late slot. Priority-weighted lateness strictly decreases while the count provably cannot rise.

Right-shift. Sweep each machine back to front, sliding every on-time job as late as it can go within its own deadline, the next job and downtime, recovering freshness without creating a miss.

Validation by lower bound rather than benchmark. The useful question is whether residual lateness is the algorithm's fault or the plant's. A capacity audit answers it combinatorially: for every deadline, count jobs due against the maximum the machine pool could physically complete by then respecting downtime, and take the largest shortfall, which is a valid floor under any schedule. On a pinned real instance the engine matches the floor exactly, a proof of optimality on that instance rather than a comparison against a competitor. Determinism was confirmed by identical output across repeated runs, feasibility by zero routing, overlap and downtime violations, and every pinned instance is archived as a regression library.

Phase 4
Impact and scaling
Low

Packaged as a single executable with an editable configuration file read fresh each run and a self-trimming log, so the host needs no runtime installed and changing a parameter never requires a rebuild.

Because the engine reaches the bound, remaining lateness is a capacity question rather than a software one, so a what-if advisor re-runs both the engine and the bound under operational scenarios and ranks them by jobs rescued. The advisor proposes; the published schedule stays the baseline until a planner chooses.

Rebuilt onto SQL Server. The prototype read and wrote flat files; the production engine reads its inputs from SQL and writes the published schedule back to it, which is what allows a separate operator interface to render the current plan and refresh as conditions change rather than waiting for someone to circulate a file.

The scheduled unattended run awaits the automation team. Until that lands the case is graded on demonstrated rather than realised value.

Value. Production time recovered on the floor, and grinds released closer to the moment they are packed. Projected against the current manual planning baseline, not a measured result.

Phase 1
Baseline and insight
Medium

Four consequences followed from the informal arrangement: conflicts surfaced on the day rather than at planning, availability was estimated rather than computed, recurring maintenance was forgotten because nobody owned remembering, and no actuals existed at all.

The baseline for all four is unmeasured. That is both the finding and the reason this case cannot yet carry a return figure.

Phase 2
Options and rejection
High

Incremental materialisation with deterministic identifiers was rejected. The original design solved a scale problem that did not exist at this volume, at the cost of idempotency logic that would have to stay correct forever.

Wipe-and-regenerate was retained, being naturally idempotent since two runs produce the same end state, and testable as a black box. The trade accepted is that an edit does not propagate until the next run, handled by an event-triggered flow for the case that matters.

Window sizing was chosen against two platform limits at once, a query threshold and a script execution timeout, so the system stays inside both by construction rather than by luck. An earlier, larger window was reduced after the timeout was hit in testing.

Rules as data rather than as records. Non-production windows are generated from a shift table rather than authored as rules, so extending production means shrinking an existing record rather than introducing a second concept that would then need reconciling.

Phase 3
Technical execution
Very high

Availability computation. Concurrent events were being summed independently, so overlapping stoppages double-counted and a window crossing midnight lost its post-midnight portion. Replaced with an exact union of intervals on a shared absolute timeline, where each event contributes only the part of itself not already covered by an earlier one, with ties broken deterministically so two events starting in the same minute cannot both claim it. Validated against an independent brute-force implementation over 60,000 randomised cases with zero mismatches.

Release engineering. From the second release the application was modified by editing its package format directly rather than through the visual designer, which is fast and a fast way to ship a broken build. A verification suite grew alongside it, each check written after the defect it would have caught: archive integrity and re-parse of every entry, after a package the editor refused to open; a duplicate identifier and parent-link audit, after cloned controls collided with their prototypes; a bracket balance that skips string literals, after false alarms on accented labels; a statement-separator linter, after one missing character silently disabled an entire screen handler while leaving the formula perfectly balanced; a geometric overlap test evaluated per visibility mode, after a new control painted on top of an existing panel; and a z-order renumber sorted by current order, after an earlier fix was re-broken.

A set-equality audit was added separately, after a fix was applied to four copies of a calculation that existed in six places, two of which were silently overwriting the corrected values.

Phase 4
Impact and scaling
Low

In production use across 41 releases. The honest claim is that availability is now computed where it was previously estimated, a precondition for value rather than value itself, and converting it into a figure requires the prior estimate on record.

Its second return is structural: this system is the plan of record, and the scheduling engine reads machine availability, downtime and priority directly from it. It is load-bearing for another system's accuracy, which is why its data quality was worth over-engineering.

Phase 1
Baseline and insight
Medium

Nothing recorded when a machine stopped, who was told, how long anyone took to arrive, or what fixed it. Four consequences: response time unmanageable because unmeasured, escalation dependent on somebody remembering, no repair history so the same failure recurs with no record of what worked, and repairs declared complete by the person who made them rather than confirmed by the person affected.

Phase 2
Options and rejection
High

Delayed jobs per event were rejected in favour of a single periodic sweeper, which keeps the number of moving parts constant as volume grows rather than scaling with it.

A timed auto-approval was specified and then deliberately removed, so only the reporter can close a failure. An unconfirmed repair now stays open indefinitely by design, which is the correct failure mode: an open record is visible, a wrongly closed one is not.

Phase 3
Technical execution
Very high

The escalation chain is the product. An operator logs a fault against a line and the workflow notifies each role in sequence at the point it is needed, without anyone deciding to make a call or go looking for someone. Every transition is written to the log with an actor, a line and a timestamp, so who was alerted, when, and what happened next is reconstructable afterwards rather than remembered.

Detection is timestamp arithmetic with no stored counter, which makes the state condition in each query load-bearing rather than decorative. The sweep re-finds the same overdue record every pass, and the state answers whether it has already been handled, a different question from whether it is overdue. Removing that condition to simplify the query produces duplicate notifications, teaches the recipient the channel is noisy, and ends with nobody reading it.

The whole workflow was first built as an executable prototype with a simulated clock, and ten behaviours were asserted by automated test rather than verified by clicking, including that a manual escalation produces no second notification when the timed sweep later runs. The prototype remains the reference implementation: where the production build disagrees with it, the build is wrong unless a decision says otherwise.

Phase 4
Impact and scaling
Low

Both response and resolution time become computable from the append-only log with no additional instrumentation. This is the one case where the measurement problem solves itself, and the first month of operation is the baseline.

Value. Direct cost, since the app replaces the radio fleet the floor currently runs on. The second return is not costed: a breakdown call becomes a timestamped record with an owner rather than a message that may or may not have been heard.

Phase 1
Baseline and insight
Medium

A shift-change summary reports in-process inventory by line and status, data that existed upstream and nowhere anyone would look. Scheduled reports render the maintained plan as formatted email. And changeover events between consecutive orders were being entered by hand, with coverage nobody could quantify.

Phase 2
Options and rejection
High

The derivation job could have written into a new store and been reconciled later, or written into the store the application already reads. The second was chosen, which required the generation to be safe enough that it could never damage manually entered records.

Phase 3
Technical execution
Very high

Built to be safe rather than clever. Generated records carry a sentinel so nothing else is ever touched. Identifiers are deterministic, so re-running upserts instead of duplicating and the job is safe to run at any frequency. Anything starting within a short horizon is frozen, so a supervisor's live edit survives. The detection function takes no database connection, so the rules can be tested against a static extract exactly as they run in production. And any case resting on an inferred flag goes to a review list rather than silently producing a confident answer.

Lesson carried forward. A source table did not use its display column names. Querying by them returned nulls with no error, producing a green run and an empty report. The authoritative names lived in the application package's own metadata. Trust the system, not its documentation, and verify every field before anything depends on it.

Phase 4
Impact and scaling
Low

The shift summary runs twice daily in production. The derivation job detects four event types from plan structure, removing a manual entry step whose coverage was previously unknown.

Value. Not costed, and deliberately so. The return is that consumption and remaining stock are visible per shift rather than reconstructed after the fact, which is what stops green coffee ageing out of specification in a corner of the warehouse. Converting that into a figure needs the prior write-off rate on record, and it is not.

Phase 1
Baseline and insight
Medium

Records existed but only individually. No view answered which defect types drove loss, which lines recurred, or what proportion of the activity resolved to nothing.

Phase 2
Options and rejection
High

A defect Pareto could be weighted by event count or by confirmed loss. Weighting by confirmed loss was chosen and it reorders the priority list substantially against the intuitive ranking, because the most frequently raised defect is not the most costly one.

Phase 3
Technical execution
Very high

Six views over the same record set: overview, per-line drill-down, defect Pareto, false-alarm analysis, chronic recurrence pairs, and method notes. The modelling choice that produced the finding was separating volume quarantined from volume confirmed as loss, two different quantities that were being read as one.

Roughly half of all events turned out to be full false alarms: material pulled and inspected with nothing ultimately rejected. The gap between quarantined and confirmed is inspection overhead nobody was measuring, and it is larger than the confirmed loss itself.

Delivered as a generated report, not a dashboard. The six views build into a single self-contained HTML file from the historical record, sliced by defect, line, period and shift, so the same question can be asked at any level without anyone holding a licence or learning a tool. It regenerates from source rather than being maintained by hand.

A detector sits on top of the same data. It watches for recurring patterns and chronic pairs as they form and raises a hypercare alert while the problem is still small, which is the difference between a report that explains last quarter and a system that changes this one. Both the reporting and the alerting were scoped in a three-day Kaizen with continuous improvement, quality, maintenance and production in the same room.

Phase 4
Impact and scaling
Low

The overhead is priced as false-alarm events multiplied by the cost of a single quarantine event, a figure quality can supply directly. False-alarm rate by defect type points at which inspection criteria are mis-calibrated rather than at the lines.

Value. Inspection overhead avoided, priced from what a single quarantine event costs. The case stays graded projected until that cost is confirmed from quality's own records, since the whole figure scales with it.

Phase 1
Baseline and insight
Medium

A scheduler planning against theoretical line rates schedules against a fiction. The gap between nameplate and actual varies by line and drifts over time, so the conversion has to be forecast rather than assumed.

Phase 2
Options and rejection
High

Selecting a single forecasting method was rejected, because no one method wins across every line. Nine run in competition instead, scored per line by rolling validation with no look-ahead, and the lowest out-of-sample error wins. Normal-theory prediction intervals were also rejected in favour of intervals drawn from a 10,000-sample simulation, which does not assume a distribution shape the data may not have.

The obvious objection, that re-selecting the method constantly is not viable, was answered rather than argued: a back-test measures how often the winning method changes as history grows, converting the instability into a per-line re-evaluation cadence.

Phase 3
Technical execution
Very high

Interface design. The forecast never enters the scheduler directly. It is converted once into a consumption rate, and the scheduler consumes that single quantity and performs no efficiency arithmetic of its own. That one-quantity contract is what allowed the two models to be developed, corrected and eventually replaced independently, and re-introducing the division was one of the documented defects.

Validation and self-audit. Both models were validated against a discrete-event simulation of current and future state before deployment. The written report was then audited against the deployed code, producing 34 documented discrepancies, including a methodology mismatch where the report described one technique and the shipped tool implemented another.

Phase 4
Impact and scaling
Low

Superseded by the production engine, which carries the deployment. Retained here because it is where the method came from, and because the self-audit is the habit the rest of this portfolio is built on.

How these projects are run

What recurs across all seven, and what makes the validation sections above possible rather than aspirational.

01
Build the instrument that says you are wrong

A combinatorial lower bound to reveal whether a scheduler is failing or at a wall. A payroll reconciliation to test a parser nobody else would have questioned. Linters written after the two specific defects that got through. Each is a check on the author, not a demonstration for the reader.

02
Reject on a property, not on a score

Every rejected option names the structural property that disqualified it: non-reproducibility, a violated ratio assumption, an over-specified modulus, an objective ordered wrongly. A rejection without a named property is a preference.

03
Cleansheet from the bottom

Cost models built from mass, rate, cycle time and yield loss rather than estimated top-down, so each line can be challenged individually. It also reorders priorities: in the staffing case it showed that splitting the benefit load into its fixed and variable tranches moved the recommended answer, which a single blended rate would have hidden.

04
Surface the bad quarter

A plan presented as a large annual number that loses money in its opening quarter loses the room by week four. Both the negative opening period and the concentration of savings into one quarter are stated up front, not averaged away.

05
Removing a feature counts as progress

An editing path that could silently destroy a group of records became delete-only. A timed auto-approval was deleted so only a human closes a job. Both removals came after the mechanism was understood well enough to see the harm.

06
Grade the evidence, then publish the count

Applying the grading strictly produces fewer verified claims than a portfolio would like. Publishing that count is what makes the verified ones worth believing.

That is the portfolio.

If any of it is relevant to something you are working on, the fastest route is email. The one-page CV is a click away, and LinkedIn has the rest.

LinkedIn ↗
Kevin Raad · Montréal