What a Sous-Chef Teaches You About Letting Edge Devices Think for Themselves

The head chef at a busy brunch spot doesn't flip every pancake. That's what the sous-chef does. The sous-chef tastes, adjusts heat, swaps ingredients when the hollandaise breaks—all without asking permission. That delegation isn't lazy. It's survival.

Edge computing works the same way. Instead of streaming every sensor reading to the cloud, you let the device decide. But the question is: when do you trust the sous-chef, and when do you call the head chef back in?

A Line Cook in the Data Center: Where Edge Autonomy Shows Up

The Breakfast Rush Nobody Warned You About

Picture a Saturday brunch service: tickets spitting out of the printer, the expo calling for two eggs benedict, a French toast, and a salmon bowl — all due within minutes. A good line cook doesn't radio the head chef to ask whether to fire the eggs now. They glance at the ticket, check the pass, and decide. That split-second judgment — fire the eggs, hold the salmon, adjust the heat — is exactly what edge devices must replicate when the cloud is too slow or absent. The catch: most teams design edge nodes to ask permission for every move, turning them into hesitant prep cooks who freeze without a manager on the line.

Wrong order entirely.

I have watched a factory robot arm wait 400 milliseconds for a cloud-based model to classify a defect — an eternity on a high-speed conveyor. By the time the arm could react, the defective part was already in the packaging bin. The fix was brutally simple: train the edge camera to recognize the three most common flaws locally, and only phone home when it saw something it didn't recognize. That decision — act or ask — cut the response lag to 12 milliseconds. The trade-off? We accepted occasional false negatives on rare anomalies. Worth it. The line didn't stop.

Autonomy isn't about replacing the chef. It's about trusting the line cook to handle the ticket they can see, and only shouting for help when the order makes no sense.

— hardware lead, food processing rollout

Latency Is the Enemy, but So Is the Habit of Asking

The textbook reason for edge autonomy is latency, and it's valid. A retail kiosk scanning a loyalty QR code can't tolerate a 1.2-second cloud round-trip when the customer is already fumbling for their wallet. But the deeper problem is behavioral: architects default to cloud-dependency because it feels safer. That hesitation creates a brittle system. I once debugged a smart-lock network where every door check required a cloud handshake — even when the building's local controller was three feet away. The result: during an internet outage, every door became a brick. Not a security door — a brick.

The irony is thick. Teams obsess over uptime SLAs while designing architectures that collapse the moment the WAN blinks. Edge autonomy isn't about chasing zero latency; it's about surviving the gap — those 200 milliseconds, those three seconds of packet loss, that 45-minute cloud outage nobody planned for. A sous-chef doesn't stop cooking because the walk-in cooler door is stuck. They adapt, improvise, and figure out which station needs the fresh herbs now because waiting means the table walks out.

Your edge device should operate similarly. Let it decide to heat the fryer oil when the ticket count rises. Let it reject a faulty sensor reading without waking the backend. The cost of a wrong local call is usually a burned batch of fries. The cost of always-waiting is a cold kitchen, angry servers, and a ticket rack full of complaints. Most teams skip this — they design for the happy path where the network is always fast. Then Saturday brunch hits, and the whole line locks up.

What Edge Thinkers Get Wrong About Autonomy

Confusing autonomy with independence

The most common mistake I see teams make is treating edge autonomy like a teenager borrowing the car—full keys, no curfew, and a vague hope they’ll be back by dinner. That’s not how a real kitchen runs. A good sous-chef doesn’t rewrite the menu on a whim. They know the mise en place stations, the supplier’s late-fish policy, and exactly when to page the head chef instead of guessing. Autonomy at the edge isn’t about cutting the cord. It’s about drawing a circle on the floor and saying, “Inside this line, decide. Outside it, call.”

I have watched teams deploy edge inference models with a straight face, then walk away expecting the device to handle every edge case. Wrong order. Within two weeks the model is serving stale predictions because nobody budgeted for input drift. The device was independent—nobody told it that sensor calibration shifts after 40°C or that the afternoon rush changes the data distribution. Independence without feedback loops is just neglect dressed up in architecture diagrams.

The catch is subtle: autonomy requires more communication than centralised control, not less. A head chef who never checks in on the line loses the kitchen. A device that never publishes confidence scores or heartbeat telemetry becomes a black box. The trade-off stings—you add edge processing to reduce latency, but you must also add local observability and bounded retry logic. That feels backwards. It isn’t.

The myth of 'set and forget'

I hear it in every second planning session: “We’ll deploy the model, the edge node runs it, done.” That sentence should trigger an alarm. No surgical instrument, no kitchen station, and no inference pipeline runs untouched for six months without drifting. The odd part is—teams that would never skip monitoring for their cloud services happily ship a Raspberry Pi to a factory floor and treat it like a toaster. It’s not.

What usually breaks first is the input schema. The device expects three sensor readings; a firmware update changes the unit from Celsius to Fahrenheit. The edge node dutifully processes 37°C as 37°F and triggers a false alarm. By the time anyone notices, the reliability team has lost a shift rewriting thresholds. “Set and forget” is a lie we tell ourselves to avoid writing update pipelines for constrained hardware. The cost shows up later, always.

Most teams skip this: building a maintenance contract into the deployment. A sous-chef doesn’t walk off after brunch service—they check the walk-in, wipe the pass, and note what ran low. Your edge devices need the same ritual. A scheduled model-version check. A configurable staleness window. A dead-simple fallback: if the edge node hasn’t heard from the control plane in four hours, it stops making autonomous calls and logs everything. That’s not re-centralisation—that’s a sane boundary.

Boundaries vs. free rein

Free rein sounds liberating. It’s terrifying in practice. Hand a prep cook the full protein budget and watch them order forty pounds of bone-in duck breast when the special calls for boneless thighs. Boundaries create safety. For edge devices, the boundary is a decision permission matrix: “You can infer anomaly scores locally, but you can't sound an alarm without a human acknowledgement if the score is below 0.85.” That one rule—phrased as code, not documentation—saves teams from ghost alerts at 3 AM.

Odd bit about technology: the dull step fails first.

Odd bit about technology: the dull step fails first.

The tricky bit is designing these boundaries without over-constraining the system. Too tight, and the edge node becomes a dumb relay—you pay for compute but get zero latency benefit. Too loose, and you’re cleaning up messes you could have prevented. I have seen a team spend a month tuning exactly one threshold: the maximum number of retries before an edge device escalates a failed sensor read. That level of granularity matters. It feels like over-engineering until the third retry floods the upstream queue and the monitoring dashboard goes dark.

So what does a good boundary look like? Three things. A clear local scope (“you own inference and local caching, not routing or billing”). A mandatory escalation condition (“if confidence drops below 0.7, flag for review within 30 seconds”). And a leash that tightens over time—no edge node stays on the same permission set for a year without review. Autonomy is a skill you practice, not a switch you flip.

“The best edge nodes are the ones that know when to shut up and wait for the pass.”

— overheard from a systems engineer who used to run a garde-manger station, during a post-mortem on a burst data event

Recipes That Work: Patterns for Edge Decision-Making

Local inference for time-critical tasks—no time to phone home

The simplest pattern that works: keep the fastest path on the device itself. A sous-chef doesn't radio the head chef to ask whether the onions are burning—they pull the pan off the heat. On edge hardware, that means running a lightweight model locally for decisions that break if you wait. Temperature thresholds, vibration spikes, a camera frame that just lost all contrast. I have seen teams try to send every sensor read to the cloud and wonder why their system stutters. The catch: local inference is usually dumber than the cloud version. You trade peak accuracy for speed. That's fine—as long as you know which tasks need speed more than they need perfection.

The pitfall is scope creep. Once a local model works for one thing, engineers want it for everything. Don't. A 50-millisecond inference on-device beats a 400-millisecond round trip—but only if the model is small enough to not starve other processes. We fixed this by setting a hard wall: if the local model's confidence drops below 0.85, pass the decision up. That leads to the second pattern.

Fallback to cloud when confidence drops—safe autonomy

Autonomy doesn't mean isolation. The sous-chef tastes the sauce, hesitates, and walks to the pass for a second opinion. Edge devices should behave the same way. The pattern is simple: run local inference first, check a confidence score, and if the result is fuzzy—hand off to a cloud model that has more context and more parameters. Most teams skip this: they either trust the edge completely (and ship bad decisions) or distrust it entirely (and defeat the point). The middle path is a threshold. Set it too high and you phone home constantly; set it too low and you accept garbage. We landed on 0.88 for vision tasks and 0.92 for numeric anomaly detection—your mileage will differ.

‘Let the edge make the easy calls. Let the cloud untangle the mess. Your latency budget decides the line.’

— infrastructure lead at a manufacturing deployment, after burning three weeks tuning thresholds

That sounds fine until the network drops. Then the edge has to make the hard call alone—or fail safely. The pattern demands a third state: if the cloud is unreachable and confidence is low, default to a conservative action (stop the line, hold the part, alert a human). Wrong order hurts less than confident wrong order.

Gradual autonomy with monitoring—trust but verify

The sous-chef doesn't start by managing the entire station solo. They learn one prep task, then another, then a cook line. Gradual autonomy on edge devices means starting with read-only decisions—flag a problem but don't act on it—then, after proving out, escalate to automated action. I have watched teams flip autonomy on overnight and revert within a day. The seam blows out because nobody monitored the false-positive rate. The better approach: ship the device with logging-only mode for a week. Measure how often it would have acted. Compare against human judgments. Then enable execution.

The monitoring part is what usually breaks first. Teams log decisions but forget to log the context—what was the confidence score? What was the network latency at the moment of fallback? What time of day? Without those traces, you can't tell if the edge is degrading or the data distribution shifted. One concrete anecdote: a client's edge node started misclassifying parts at 3pm every Tuesday. Turns out a warehouse door opened at that hour, flooding the camera with sunlight. The local model never saw that during training. Gradual autonomy with sparse monitoring—they caught it only after a recall. Painful.

Start with one station. Pick a decision that matters but won't sink the shift if it misfires. Run it on-device with a confidence floor and a cloud fallback. Log everything. Then let the next station watch. That's the recipe.

Bad Brunch Service: Anti-Patterns and Why Teams Revert

Over-delegating Without Supervision — You Handed Off the Pass

I watched a team push full model inference to fifty point-of-sale terminals, then walk away. Day one was poetry. Day three: one terminal started classifying every credit-card decline as a training error and auto-retrying payments. The kitchen metaphor is exact—you wouldn’t hand a new garde manger a blowtorch and leave for a smoke. Yet architects routinely ship edge models with zero feedback loops. The edge thinks, yes. But does it report how it thought? Most revert to centralized models not because the edge failed, but because the team never installed a simple tilt sensor on the autonomy. No alert when confidence dips below 0.7. No human-in-the-middle for the first five anomalous decisions. That hurts.

The catch is that supervision feels like heresy when you’ve sold executives on “self-healing” systems. So teams skip guardrails. Then the brunch rush hits—a sudden change in ingredient supply, a new POS firmware update—and the edge goes rogue. One client told me, “We had 400 devices serving stale recommendations for six hours. By the time we noticed, the repair cost was ten times the compute savings.” Drop a human back into the loop, but only for exceptions. Not for every ticket. That’s not autonomy; that’s abdication with a dashboard.

—

Ignoring Data Drift Until It Burns You — Your Recipe Is Rotting

Data drift sounds academic until your edge model starts classifying medium-rare steaks as overcooked. The sous-chef knows that a Tuesday brunch crowd behaves nothing like a Saturday dinner service—portion sizes shift, ticket times compress, the expo line scrambles. Edge models trained on last month’s flow will choke on today’s. I have seen a factory deploy a vision model for defect detection, retrain it once, and then let it run unmonitored for fourteen months. The camera lens fouled. The lighting shifted. The product packaging changed subtly. The model quietly drifted from 94% accuracy to 62%.

“Drift isn’t a bug. It’s the system telling you the world moved while your model stayed still.”

— Operations lead at a food-service robotics startup, after a bad brunch service that sent 300 undercooked orders to the pass

Odd bit about technology: the dull step fails first.

Odd bit about technology: the dull step fails first.

What usually breaks first is the retraining pipeline, or rather the lack of one. Teams assume the edge will self-correct. Wrong order. Edge devices can nudge their own weights—if you build a drift-detection trigger and a gateway to pull fresh parameters. The teams that revert are the ones who skipped that step. They own a pile of dark endpoints, each diverging in its own direction. The fix is boring: schedule weekly drift checks, compare inference distributions against a held-out slice of production data. Sound tedious? Good. It beats a Saturday morning panic where you have to SSH into 200 terminals one by one.

—

One-Size-Fits-All Models That Fail in the Field

The worst anti-pattern is the universal model. “Train once, ship everywhere” sounds efficient. Then you push the same inventory-forecast model to a humid kitchen in Bangkok and a dry commissary in Denver, and both fail for opposite reasons. The edge is not uniform. Device memory varies. Sensor noise differs. The data distribution at station 4 is not the same as station 7—the ticket printer is older, the cook prefers a different plating sequence, the camera angle is off by six degrees. A single model can't absorb that variance without turning into a blurry average that pleases nobody.

Most teams revert because they can't maintain N separate models for N devices. The trick is not to. Use a base model plus per-station adapters—tiny fine‑tuned heads that absorb local quirks while sharing the backbone. I fixed a deployment once by splitting the fleet into three clusters: high-traffic, low-traffic, and experimental. Each cluster got its own schedule and threshold. One model per cluster, not per device. That’s the sweet spot. The teams that ignore this end up back at a centralized API, trading latency for simplicity. You don’t need a hundred unique recipes. You need three that actually fit your stations, and the humility to split them.

The Cost of Keeping the Line Clean: Maintenance and Drift

Model Retraining Cycles: The Kitchen Prep Nobody Schedules

You trained a model. It shipped. Deployment felt like nailing a perfect 86 during a Friday rush. Then three weeks pass, and the edge device starts misclassifying—call it the prep cook who suddenly can't tell romaine from iceberg. The drift is invisible until the ticket comes back wrong. I have watched teams pour weeks into initial performance, then treat retraining like an afterthought, a chore to "get to later." Later never comes. The device serves bad predictions long before anyone notices, and by then the data distribution has shifted so far that a simple fine-tune won't fix it. That sounds fine until your automated system is rejecting valid orders based on a pattern that died two menu revisions ago.

Retraining is not a switch you flip.

Most teams skip this: edge devices accumulate local quirks. One camera sees different lighting; one sensor basket runs hotter. You can't push a single global update and expect it to land everywhere. The operational cost is not just compute cycles—it's the human time to gather edge-specific logs, label the drift, and decide whether the local model needs a patch or a full rebuild. The trade-off bites hard: update too often and you burn DevOps hours; update too seldom and accuracy decays like a forgotten roux. The catch is that no dashboard tells you the *right* interval. You discover it by watching the seam blow out during a routine Saturday service.

Monitoring Edge Performance at Scale

Centralized monitoring is a lie.

You can see the aggregate accuracy metric—looks green. But aggregate hides the single bad node in station three that has been mis-firing for six days. Edge devices are not uniform; they diverge. One runs on a flaky network, another has a degraded sensor, a third works fine but gets weird input because the line cook changed the prep order. What usually breaks first is the monitoring pipeline itself. It generates alerts nobody triages because the noise-to-signal ratio is brutal. I have seen dashboards with forty-seven green checks and one red warning that nobody clicks on. The red warning? That was the node serving the brunch shift. Wrong order. Bad fix.

Autonomy without observability is just a recipe for finding out too late.

— A field service engineer, OEM equipment support

— overheard at an edge ops postmortem

Monitoring at scale demands a different posture: you watch for *relative* drift, not absolute thresholds. Compare each device against its own historical baseline, not a global norm. The pitfall is tooling—most platforms sell you nice charts for central servers but treat edge devices as thin clients. They're not. Each one is a tiny kitchen with its own rhythm, and the monitoring cost grows linearly with device count. That hits budgets fast. You might find yourself spending more on observation than on inference. The question is not can you monitor—it's whether your team can tolerate the signal they actually get.

When to Retire a Local Model

This is the hardest call. Nobody wants to pull a model that still hits 88 percent accuracy—until you realize that the 12 percent it misses is the exact edge case your operation can't afford. Retirement feels like failure, but keeping a drifting model live is a slow bleed. We fixed this by setting an explicit kill criteria before deploy: what error rate triggers rollback? what data-age threshold forces a rebuild? Write it down. Share it with the team. The alternative is a zombie model that runs for months, accumulating technical debt while everyone assumes "someone else" will catch it. That hurts.

Retire the model. Not the problem.

When the Head Chef Shouldn't Leave the Kitchen

When the Head Chef Shouldn't Leave the Kitchen

Most edge architecture talks celebrate delegation. Push decision-making down. Let the fry station run its own inventory. The sous-chef philosophy sounds liberating until somebody orders a table of twelve with four separate shellfish allergies, the tickets are pouring in, and the line cook at station three runs out of 86'd items because the edge node decided to reorder based on yesterday's brunch traffic instead of today's private event. That's the moment you realize: some decisions belong at the pass.

The head chef stays in the kitchen when the cost of a wrong local decision exceeds the latency benefit of making it quickly. I have watched teams push model inference to edge devices for predictive maintenance on a $40 sensor—and then lose a full shift of production data because the device hallucinated a calibration error and shut down an assembly line. The edge thought for itself. It thought wrong. And the cloud, which would have cross-checked the reading against three other sensors, never got a vote.

Reality check: name the technology owner or stop.

Reality check: name the technology owner or stop.

Regulatory constraints create another hard boundary. Healthcare, aviation, and financial auditing demand a single source of truth with immutable logs. Edge devices, by design, operate in partitioned, occasionally disconnected states. You can't reconstruct an audit trail from five nodes that each decided to truncate their logs because storage was tight. The catch is brutal: autonomy that violates compliance isn't autonomy—it's liability. One med-tech startup I consulted tried to run patient triage inference at the bedside terminal. Clever. Then the regulator asked for the full decision chain on a flagged reading. The edge had already overwritten the intermediate probabilities. That hurt.

'The edge can decide quickly. It can't yet explain itself consistently—and auditors require explanation, not speed.'

— Lead architect, regulated health-platform migration

Then there are the edge cases too rare to train for. A grocery chain let edge cameras manage checkout exceptions—unexpected item in bagging area, price mismatches, customer disputes. It worked fine for 98% of transactions. The remaining 2% included a toddler sitting on the scale, a customer returning a bag of ice that had melted, and a competitor filming the layout. Each required human judgment the model had never seen. The edge defaulted to a security override that froze the entire lane. Wrong order. The store manager had to physically reboot the station while a line formed out the door. The savings from eliminating one cashier evaporated in fifteen minutes of lost sales.

The deciding factor is whether the decision has irreversible downstream cost. If a mistaken order on station two means the table waits eight extra minutes—fine, the chef catches it at plating. If a mistaken inference in a manufacturing cell means a $200,000 die crushes itself, the cloud needs to sign off. I have seen teams draw this line too conservatively, keeping every decision centralized and wondering why their edge pilot showed zero latency improvement. The opposite error is just as common: letting the edge decide everything, then blaming the architecture when a low-probability failure cascades into a systems event. The head chef leaves the kitchen only when the prep is predictable, the recipes are frozen, and the diners are repeat customers. For the private event with the VIP guest who has never eaten there before—stay at the pass. Watch the tickets. Keep the cloud in the loop.

Open Questions Every Edge Architect Asks

How to measure decision quality locally?

You can't stare at a single metric and call it done. Accuracy on the training set is a lie the sous-chef tells the head chef before service starts. The real test happens when the grill station decides to hold a salmon order for forty seconds because the pass is backed up — and the dining room doesn't notice. I have seen teams obsess over latency percentiles while their edge devices confidently misclassify a burnt pan as 'ready to plate'. The catch is that local decision quality requires local ground truth, which most teams don't collect. You need a feedback loop that answers: did that decision make the next minute better or worse? Without it, you're measuring shadows.

Wrong order. Most architects start with precision-recall curves. What they should start with is the cost of being wrong. A false positive that sends a redundant ingredient order costs fifty dollars. A false negative that lets a spoiled batch through costs a reputation. Measure what hurts.

What's the right confidence threshold?

Pick any threshold and you have already made a trade-off. A high bar — 0.95 or above — means the edge device stays silent most of the time, punting decisions back to the central kitchen. That defeats the purpose of autonomy. A low bar, say 0.7, and you will see the device acting on noise: misreading a temporary steam cloud as a fire hazard and killing the fryer. The odd part is that the optimal threshold shifts with every station and every hour. The morning prep rush tolerates more false positives than the final dinner push. We fixed this by making thresholds time-aware — the grill station drops its bar after 7 PM because the senior chef is distracted by closing duties. That works until you realize the threshold is a proxy for a deeper problem: you don't trust the model. And you should not, fully — but you also cannot keep the head chef in the kitchen every night.

A single number for all edge nodes is a trap. You want a range, with a clear escalation path when confidence falls into the gray zone. Let the device act in the green, log in the yellow, and ask in the red. That sounds simple. Most teams skip the yellow entirely.

Can edge models learn from each other without a central server?

Yes, but the pattern is brittle. Federated learning sounds elegant on a slide deck — each device trains locally, shares only weight updates, and the collective improves without exposing raw data. In practice, the stations drift apart. One grill learns to handle a new supplier's chicken thighs that cook ten percent faster; another station never sees that data because it runs a different shift. The aggregated model becomes a bland compromise that helps nobody. I have watched teams revert to central training after three rounds because the edge models started disagreeing on what 'medium-rare' means — and the pass could not reconcile two conflicting temperature recommendations. That hurts.

The alternative is gossip protocols: devices share small model updates directly with their nearest neighbors, like line cooks calling across the kitchen: 'Hey, I just learned the fryer runs hot on the left side.' This works in simulation. In real kitchens, network partitions, shift changes, and one station running a different firmware version break the gossip loop. The open question is not whether they can learn from each other, but whether the coordination overhead costs more than the improvement it buys.

'Every time we let two edge devices talk to each other without central approval, we created a new kind of incident — and a new kind of speed.'

— infrastructure lead at a food-tech startup, after their third rollback

The unresolved tension is this: central coordination guarantees consistency but caps autonomy. Pure peer-to-peer learning maximizes adaptation at the cost of chaos. No architecture solves both. Your job is to pick which flavor of failure you can stomach — and measure whether the trade-off shrinks over time. Start with two stations that share a physical shift. Let them exchange confidence logs, not model weights. Watch whether the decisions converge or diverge over a week. That experiment will tell you more than any whitepaper.

Your Next Experiment: Picking One Station to Delegate

Start with a low-risk, high-repetition task

Your first autonomous edge station should bore you. That’s the point. A camera checking whether a conveyor belt has stopped. A temperature sensor deciding to pre-cool a room before a shift starts—not a full HVAC rewire. I have seen teams burn months trying to make an edge node negotiate load with a central orchestrator. They crash on the first Monday. Instead, pick a task a sous-chef would hate: the one where muscle memory already exists, where the failure state is “try again in thirty seconds,” not “order a new batch of perishables.” The catch is that boring tasks still require sharp boundaries. Define exactly what the edge device cannot do. No budget overrides. No vendor handshakes. Just one loop: read sensor, compare threshold, act or escalate.

That sounds too simple. Wrong order.

Most autonomy attempts fail not because the logic is complex but because the scope leaks. You give a device permission to adjust airflow in one server row, and two sprints later someone wants it balancing grid demand across three zones. Don’t. Keep the experiment to one station—one Raspberry Pi, one PLC, one conveyor-belt camera—for two full operational cycles. A week, maybe two. Watch what breaks when nobody is watching.

Set clear success metrics and rollback plan

Before you push the first decision to the edge, write the stop condition on a sticky note and put it on your monitor. “If false-positive rate exceeds 2%, revert to human judgment within four hours.” Not vague. Not “we’ll monitor and adjust.” An actual number tied to an automated fallback. The pitfall here is overconfidence: teams often define success as “device ran without error,” which tells you nothing about whether the decision was correct. Measure the outcome, not the uptime. Did the pre-cooling actually reduce peak power draw? Did the conveyor camera catch all jams? If yes, fine. If not, the rollback plan isn’t failure—it’s data. The rollback itself must be immediate. I once watched an engineer say “we can fix the dispatch logic tomorrow” while a batch of compute jobs silently queued to a dead node overnight. That hurts. Rollback should be one config flag, not a weekend rearchitecture.

“Autonomy without a kill switch is just a slow disaster waiting for a network partition.”

— field notes from a factory-floor edge rollout, 2023

That quote lives in my notebook because the teams that ignore it usually learn the hard way. Your rollback plan should survive a network outage. If the edge can’t phone home, it should freeze decisions, not guess.

Iterate based on real feedback

After two weeks, sit down with the data and the person who previously owned that task. Not a dashboard review—a conversation. “Did you trust it? When did you override it? What did it miss that you caught by feel?” The edge device doesn’t have a gut. It doesn’t know that the third shift operator always leaves the door ajar for five minutes. You do. That human feedback is the single richest signal you’ll get, yet most architects skip straight to log analysis. The tricky bit is that iteration often reveals scope creep again—someone will say “if it can handle that, why not also handle this?” Push back. Run the same experiment for another cycle with a single adjustment. Maybe tighten the threshold. Maybe extend the timeout. But change one variable. That’s how you learn whether the edge can actually think—or whether it just survived the easy week.