From order, chaos. From courage, fear. From strength, weakness.
— The 36 Stratagems, "Make a Sound in the East, Strike in the West"
Alex never looked for a job. The job looked for him.
That was Alex's last story—the $660K Axon platform, the layoffs, page 37 of his notebook, 847 × 37%. Three weeks later, Axon's automatic rollback overwrote a manual hotfix and cost the company $630K. He wrote an email with one line: "This is what you get for $660,000."
He CC'd four people—the former CEO, Wang Lei, the CTO of a FinTech firm, and Mike, CTO of MedTech. Mike replied with four words: "Monday morning. My office."
Monday morning, Alex signed. Principal Architect. Double the compensation. Reporting directly to Mike. The former CEO called late that night, begging him to come back—but Alex was already on the contract.
"No. MedTech's offer is already in. Tell Wang Lei—his Axon is great at generating pretty reports. Just not at taking calls at 3 AM."
He hung up. And he brought that lesson to MedTech.
From the guy who got replaced to the guy watching AI systems grade other people's work. He knew what those pretty green numbers on the dashboard really meant. And he knew what they were hiding.
MedTech runs a medical supply chain—hospitals order gloves, IV tubes, and dressings through the platform, and it connects them with suppliers. Every order, from generation to dispatch, goes through three layers of compliance: supplier qualification verification, batch number traceability, and sterilization record alignment. No step gets skipped. About 100,000 orders a day flow through the pipeline. Alex owns the monitoring architecture. Everything is auditable.
Three months in. No monitor on his desk—just a laptop and that worn-out, hardcover notebook, exactly as it was on day one. Mike's office is next door. Alex sits in the back row at meetings, says the least, doesn't pick sides, and doesn't waste words on Slack. When he runs into Mike in the hallway, he stops and chats—Mike personally recruited him, and he respects that. But that's it. He never pushes. He files tickets not because he expects someone to fix them—but because he's waiting for a chance to fix them himself.
Then he found something.
Discovery
MedTech's AI compliance monitoring system generates a summary report every morning, pushed to the QA team and supplier management system. All the metrics are green—99.97% order compliance rate, 99.82% supplier coverage, 99.4% sterilization record alignment. Data enters the pipeline and doesn't leave. Reports can't be revised after generation. An audit could drop in at any time.
But Alex noticed something. The automatic summary module silently strips out any anomaly flagged with confidence below 70% before the final output.
It's not data deletion—it just doesn't make it into the summary. The raw logs have it, the database has it, but the audit report doesn't show it. By industry standards, this isn't a violation—summaries are sampling by design, and compliance guidelines allow for a tolerance margin. But Alex ran the numbers: 1,530 flagged anomalies had been filtered out over the past quarter, of which 58 were later confirmed as genuine issues in the production environment—expired supplier certifications, mismatched sterilization batch numbers, missing cold-chain temperature records. On a daily average, the summary reports about 140 compliance flags. The filtered-out ones, roughly 17 per day, make up about 12% of the summary content. Not much—but enough for the QA department to notice during a quarterly review.
He filed a ticket. It got bounced three times and skipped the approval queue—not because the compliance lead missed it, but because someone had already decided before him. The note field had four words: "Summary items: not required." Below that, a line from the Compliance Director: "Threshold configuration has been finalized by the technical committee. No ad-hoc adjustments."
Alex didn't follow up. He never does. But he remembered that number: 1,530. The same way he remembered 847 × 37%.
He pulled the worn-out hardcover notebook from his drawer and flipped to page 37. The 847 × 37% calculation was still there—carried over from the Axon mess three months ago. Below it, he wrote a new line: 1,530.
Feint East
Alex has a habit of scanning the monitoring dashboard around 2 PM every afternoon—not for red alerts, but for yellow ones. The system's daily anomaly batch processing catches up around this window, so the early-morning spikes surface in the afternoon. Axon taught him one thing: the most dangerous signals never show up in red.
Wednesday, 2:14 PM. MedTech's AI anomaly detection system fired an alert:
[YELLOW] I/O Wait Time Anomaly
Host: medtech-compliance-svr-01
Baseline: 12ms avg
Current: 38.4ms peak (3.2× baseline)
Window: 01:00 - 01:30 UTC
Impact: Compliance summary generation pipeline
Alex saw it. He stared at it for three seconds.
Then he opened the compliance team's Slack channel and dropped a message with a screenshot attached:
"The compliance report generation server's I/O wait time spiked three times between 1:00 and 1:30 AM, peaking at 3.2× the baseline. Those hours overlap with the automatic summary module's runtime. Not sure if there's data loss risk—suggest we confirm."
He chose the words "data loss" deliberately. He knew exactly how the compliance lead would react to those two words.
Seven minutes later, the compliance lead replied: "I'll start a group."
The group was called "Compliance Report Server I/O Anomaly Investigation — Data Integrity Check." It included Alex, the ops lead, a compliance engineer, and Mike.
Alex's first message was a shared doc. He laid out the investigation steps: check disk health, verify the summary module's run logs, compare input and output record counts. He put himself on the first shift.
The ops lead reported first: "Disks are clean. No SMART alerts." His tone said "I knew it wasn't a hardware issue"—he'd been pulled into this and thought it was a waste of time.
The compliance engineer followed up on logs and record counts: "Timestamps line up with the I/O spikes. No gaps. Record counts match too. No indication of data loss—but I'd recommend running the input-output comparison one more time to be sure."
The compliance lead wasn't satisfied: "Run it again. Post the results."
Alex waited for them to finish. Everything matched his prediction. Then he opened his terminal—checked the disks, reviewed the logs, verified the record counts—all from the same window. He was answering a question he already knew the answer to: the I/O spike was caused by the backup window overlapping with the summary generation window. Not a hardware failure. Resource contention. He knew the answer, but resource contention wasn't worth discussing in the group.
By 11 PM, three people were still online in the investigation group. The compliance engineer sent the last message: "Both comparison rounds passed. No discrepancy." The compliance lead replied: "Let's leave it here. We'll see what Mike says tomorrow."
The group went quiet. The investigation was paused.
Strike West
Thursday, 2:03 AM. Nobody checks Slack at 2 AM.
The investigation was paused. But Alex wasn't. He opened his terminal—still there, still in the afternoon's investigation directory—and pulled up the compliance report generation system's config file.
He'd already read the code. The summary module's filter threshold sat at line 84 of the config:
{
"summary_confidence_threshold": 0.7,
"max_entries_per_report": 200,
"exclude_below_threshold": true
}
The original engineer who wrote this module figured low-confidence flags weren't worth reporting—they'd just clutter the audit trail with noise. Back when data volume was low, that was probably the right call. Low confidence almost always meant false positives.
But MedTech's order volume had doubled since last year. With ~100,000 orders a day flowing through, low confidence no longer meant false positive—it meant "the system isn't sure." And the things a system isn't sure about are exactly the things a human needs to look at. That was the most expensive lesson Alex learned from Axon: What the AI doesn't tell you matters more than what it does.
He changed line 84 from 0.7 to 0.0. Saved. Exited.
He didn't modify the comments. He didn't leave a log entry. In the change description, he wrote one line: "Summary module config parameter review."
It wasn't the truth. But it wasn't a lie. He had reviewed the parameter. He just didn't mention what he'd changed.
MedTech allows Principal-level engineers to push configuration changes directly to production. No secondary approval required.
The change deployed at 2:17 AM.
The next morning, Mike asked in the group: "Any conclusion?"
Alex posted a detailed investigation log. Disks were fine. Logs showed no errors. Input and output record counts matched exactly. No evidence of data loss. Recommended enabling more detailed logging on the next summary generation run for continued observation.
Mike read through the whole thing—Alex was someone he'd personally pulled out of the Axon disaster. He wouldn't lie about data. Mike didn't press further. He just dropped a 👍.
One by one, people left the group. The compliance lead exhaled—no data loss, reports go out as usual. The ops lead dismissed the alert notification.
But Alex didn't close that terminal window.
Traces
Three weeks later, a Tuesday. The compliance lead was reviewing the quarterly report when he noticed something odd: the compliance summary had grown by about 12% over the last three weeks. He checked the change log and found a config review submitted by Alex. He grabbed a screenshot and walked over to Alex's desk.
"What did you change?"
Alex didn't look up. He finished writing in the hardcover notebook, closed it, and only then spoke.
"Config review. Compared the summary module parameters against the design document."
"The summary_confidence_threshold—did you touch it?"
Alex paused. He knew the compliance lead knew enough to recognize that parameter name.
"I zeroed it out."
"Why?"
"Because out of the 1,530 filtered flags, 58 were real. You should have been seeing them."
The compliance lead stood there for maybe ten seconds, staring at the back of Alex's head.
Then he said:
"Next time, tell me first."
"Would you have approved it?"
The compliance lead didn't answer. He stood a moment longer, then lowered his voice: "The director saw the change record. I blocked it from going further. But next time—at least let me know."
He turned and walked away.
After he left, Alex opened the P4 ticket and changed its status to "Completed — Config Optimization."
The notification dropped into the compliance team's queue. Over three hundred other tickets were waiting in that same queue. Nobody else would ever open this one.
The Third Cup
That night, Alex walked out of the office building. A little past 1 AM, he took a different route home.
He passed a café called The Third Cup. The light was still on inside—not harsh white, but a warm yellow, like an old desk lamp.
He pushed the door open.
This was his first time inside. The place was small. The bar took up most of the space, with only two or three tables in the back. The air smelled of coffee, old books, and wood. The person behind the counter looked up, said nothing, placed a ceramic cup on the counter, and started wiping the rim with a white cloth—slowly, the way someone does when they're in no hurry.
Alex ordered a hot coffee. While he waited, he noticed a handwritten tag tucked under the coaster. The handwriting wasn't fresh, and the edges were worn—he wasn't the first person to pick it up.
"I have coffee. Do you have a story?"
Alex picked it up and held it for two seconds. He didn't sit down right away. He glanced at the person behind the counter—still wiping the cup, not looking at him, waiting.
Alex put the tag back under the coaster, took his coffee, and sat by the window. He didn't check his phone. He didn't open the hardcover notebook. He just sat there, drinking his coffee, one sip at a time. Fifteen minutes. He didn't say a word.
When he got up to leave, the person behind the counter didn't ask what his story was. He just said:
"Come earlier next time."
Alex stepped outside. The night air was colder than when he'd gone in. He didn't look back. But he knew he'd be back.
That's Make a Sound in the East, Strike in the West—an I/O alert triggered a full data integrity investigation. The real fix was a single line in a config file, deployed while everyone thought the case was already closed.
🤖 AI Post-Mortem
[36 Stratagems Tactical Database v3.1] Loaded
[Tactic Match] Make a Sound in the East, Strike in the West
[Analysis Mode] Full Spectrum Scan
━━━━━━━━━━━━━━━━━━━━
Tactical Match Rating: ~96%
Operator: Alex
Action: Leveraged a yellow I/O alert to trigger a data integrity investigation,
then modified the compliance summary confidence threshold during the investigation window.
Objective: Make 1,530 silently filtered compliance flags visible
Result: Achieved — threshold zeroed, 58 genuine anomalies surfaced in the report, no direct accountability assigned
Attention Migration Mirror:
- Feint (East): One I/O anomaly screenshot + two words "data loss" → entire compliance team stared at I/O.
- Strike (West): 02:03 AM, one config parameter changed (line 84). Nobody reviews configs during an investigation.
- Aftermath: Three weeks later, compliance lead noticed a ~12% increase in summary volume. Asked why. Alex: "Because 58 of them were real."
Counter-Detection Analysis:
- Strategic Assumption Risk: If the compliance lead hadn't created the group within seven minutes, or if Mike had requested deeper investigation (config change audit), the feint window would have closed. The strategy depended on "data loss" being an unconditionally triggerable response.
- Information Asymmetry Mirror: Alex concealed the real purpose of the config change (revealing the blind spot) — the system concealed low-confidence anomalies (reducing noise). Same operation, opposite intent.
- Methodology/Tool Limitations: Alex could deploy independently at 02:00 AM because Principal-level engineers hold direct production config write access. A change requiring Security or review board approval would have required a fundamentally different approach.
- External Monitoring Signal: The Compliance Director saw the change record. The compliance lead chose not to escalate. The system's eyes had opened — but someone drew the curtains for Alex.
Core Insight:
- Alex didn't lie. He ran a real investigation and made a real diagnosis. He just directed everyone's attention to a safe exit.
- The 1,530 filtered flags weren't a bug — they were a design decision. The system's blind spot was hardcoded into line 84 of a config file. Fixing it didn't require changing the code — it required changing the designer's assumptions.
- **A feint isn't about deception — it's about moving everyone's attention away from one truth so another truth has room to be written.**
Next stratagem: Create Something Out of Nothing
P.S. English isn't my first language. I use AI to polish the writing and smooth out the rough edges. Thanks for reading. ☕ Buy me a coffee
Top comments (17)
Ngl, that's why large corporations lose millions, while small corporations lose alot less. Scale. A small corp fights to win back 1%, while large corps breeze off 10%... That compounds and the day it gets noticed, it's already cost 10x what it would have with the same diligence as a small corp. It's not that the dev's are incompetent, it's the bureaucracy behind 'management' and 'roles' that lead to valid inputs being shot down, because 'that's not your job', or 'we trust our million dollar AI over you'. While a small corps takes every input seriously and only dismisses it once proven, large corps' structure sees is as toe-stepping acting out of line. Result range from "Tell me first", to "you've been put under review", not because you're wrong, but because you're right and they see it as a threat. Whether it's a threat to their own job, or a threat to the company's investor program. Fact is, no company has earned their trillion dollar valuation on pure merit, it's been stat sheets and investments, inflation that balloons egos and guardrails investor previews above correctness... A "1000 tests ran, 1% error rate", looks better than "1100 test ran, 10% error rate". Summarizing to a confidence threshold is wrong... Instead, logs should be more descriptive, eg. tagged with 'simple retry', or 'failover', or 'data-corruption', so the scoped logs can tell the real story. Every single 'data-corruption' tagged error should be in every summary, while 'simple retry' is less useful, 'failover' is less useful. Both of those arent breaking failures, unless they hit a threshold... That's the level of detail small corps fixate on, while large corps just look at % covered.
The 1,530 filtered flags thing — that's exactly what your tagging idea fixes. 'data-corruption' always in the summary, 'simple retry' folded away unless it hits a threshold. That's the kind of detail that makes small-team diligence scale.
It comes back to an old project of mine, V.A.L.I.D. which let you tag things a little smarter than standard C# or CSLA, so it's not just 'warning, error', tag it and filter it in your log view, so you know what is code red, vs ignorable. V.A.L.I.D. was written as the definitive path for large-scale C#/F# refactoring, because it produces 80% of the code, you just declare your DTO with ValidObjects and the layout of your UI and everything is wired for you, including a MCP, Unit Tests and a UI fuzzer for REAL UI testing at scale, so you can test the actual app in use on a dummy db.
The key being, all of those 1530 errors have an origin, half are in improperly done boilerplate, the remainder are from improperly set up endpoints, data access layers and business objects (or their equivalent). So when you create the 20%, you put in 100% effort, by making sure you tag everything properly, because the overhead you save on everything else, you can spend on making sure everything is perfectly scoped, with constraints, rules, permissions, tags, etc. Without even touching AI (though the architecture does have a MCP and skill for codebase refactoring and creation to make sure the LLM doesnt mess up).
For perspective, my employer's codebase throws 3000+ warnings on each build. 99% of those could be solved with V.A.L.I.D. letting the team focus on the remaining 1% diligently. Consistency is what allows a codebase to operate for 20 years without failure, not LLM interpretability.
V.A.L.I.D. sounds like the kind of thing that makes QA actually sleep at night. From a testing perspective, consistency = testability. If everything's wired the same way, you write one test setup that works everywhere — not 30 different ones that all break for different reasons.
The UI fuzzer on a dummy db though — that's the part I'd steal. Most "AI testing" tools just screenshot-diff and call it a day. A fuzzer that hits live UI with real data patterns and checks what actually breaks? That's where testing should be heading.
And 3000 warnings per build is wild. Not because of the number — because when everything's a warning, nothing is. QA can't prioritize what's buried in noise.
Exactly. Oh upside of V.A.L.I.D. writing everything non-unique, beyond consistency, is that by generating the in-betweens, it can translate to the most optimal possible. Eg. It will actively convert your written language to a different compiled language. What you write in C#, converts to F#, so developers write easier, while it makes sure it runs faster. Result is getting over 3600 mutations (multi-rule driven concurrency across multiple UI elements at once) per second, by bypassing the VDOM entirely, actually making frameworks like Blazor useable for real apps, not just basic forms (which at max hits 650/s without rules or linkages). It's quite a piece of work if I do pat myself on the back.
3600 mutations/s is definitely worth a pat on the back. I'd do the same 😂
But real talk — how do you keep up with verifying the results at that speed? Not questioning whether it runs, just curious how you know it changed the right things after all those rounds. For testing, find speed and verify speed need to match, or faster just means harder to trace.
that's via the fuzzer, which automates the UI testing, V.A.V.I.D. highlights the affected properties in realtime on-screen for you, while the V.A.L.I.D. F# rule system handles the validations, on the backend (what changed, did it affect something else, do the numbers add up, etc.). If it hits a problem, it logs it and highlights it. Because the V.A.V.I.D. HUD is wired throughout the system, it shows you not only the UI element that bugged, but also the BO, property and method that caused it, along with the state that caused it. So you have a perfectly reproducible error scenario, which you can then fix and use that same scenario on the updated version to validate it's fixed. given the rule execution is extremely fast (Mean - 15.800 ns Error - 0.3659 ns StdDev - 0.7308 ns), you understand why it can run multiple rule checks for each step, even at 3600+ per second. And if your CPU is faster, both get faster. So it essentially creates a hard-relation between Rules and mutations that ensures that before another mutation can even happen (18.5 to be exact for my hardware, in the timespan between each mutation, which is only 270ns). Orders of magnitude faster than even top enterprise solutions (welcome to functional programming, why F# is my tied fav, alongside Rust).
V.A.V.I.D. HUD + perfectly reproducible scenario — that's the part that got me. From QA side, that's not debugging, that's turning a flaky bug into a fixed test case before the dev finishes their coffee.
15.8ns is impressive but honestly the HUD showing BO, property, method, and state at once is what stands out. That kind of traceability is what teams dream about when all they have is a log saying "something went wrong".
Question though — does this assume the dev already knows what to look for? Fast reproduction is great, but the hardest bugs aren't the ones you can reproduce — they're the ones you didn't know existed. How does V.A.L.I.D. catch those?
The confidence threshold problem here is a textbook example of why static thresholds break at scale. The 70% cutoff made sense when MedTech was handling 50K orders a day â low confidence genuinely correlated with false positives, mostly edge cases the model hadn't seen enough of. But at 100K orders, the "low confidence" bucket starts capturing a completely different distribution: not noisy false positives, but genuine edge cases that legitimate edge cases â novel supplier combinations, unusual batch configurations, cold-chain anomalies in novel contexts.
The model isn't getting worse at those thresholds. The population it's operating on has changed. The threshold that was a signal-to-noise filter has quietly become a systematic blind spot.
What makes this insidious is that it's technically compliant. The raw logs have everything. The database has everything. Only the audit report has the hole â and an auditor checking the report sees clean numbers, not the 1,530 filtered events sitting in logs nobody looked at.
This pattern shows up constantly in AI monitoring: confidence thresholds, relevance cutoffs, sampling rates â all calibrated against yesterday's data distribution, all silently degrading as the system scales. The fix isn't just lowering the threshold. It's building observability into the filtering layer itself: monitoring what gets filtered, not just what passes through.
The "yellow not red" insight is also quietly brilliant. Red alerts have response protocols. Yellow alerts have skepticism. That asymmetry is exactly what makes yellow the more dangerous lane for real anomalies to hide in.
This is exactly the pattern I see in test automation too. We optimize for what fits in the dashboard — pass rate, coverage percentage — and those numbers look great. But they're only measuring what we decided to measure. The blind spot isn't in the execution, it's in the selection of what to monitor.
"Monitoring what gets filtered, not just what passes through" — that should be a rule for dashboards everywhere. What'd you run into that made you frame it this way? Sounds like personal experience talking
Intriguing one - maybe it lacks a bit of the drama of the other episodes, but there are some subtle points well made here - and I see that this episode elicited a number of thoughtful comments, so I won't try to repeat what others have already articulated very well !
Appreciate you saying that — and you're right, this one's quieter than the others. Not every compliance war room ends in a fire drill. Sometimes the win is just getting the config changed and having no one notice 😅
Glad the subtle points landed though. Those are the ones that take the most rewriting.
All six protagonists have done their solo debut now. Which means the 36 Stratagems series is officially 1/6 done🎉. Wait — that also means 5/6 to go. 😭 Words once said gotta be delivered. Seriously though, thanks to everyone who's been reading. Comparing the new series to the old one, the likes and comments aren't even close — still blows my mind.
Next post won't be Stratagem #7 yet. Need to pause, do a proper retrospective, and figure out what I've learned so far. More soon.🤣
Okay... I did not expect this post to go in this direction. 😄 I thought it would be another AI compliance article, but that twist with the hidden low-confidence alerts genuinely caught me by surprise.
What stood out to me the most wasn't the configuration change itself—it was the moment when Alex realized that 1,530 low-confidence alerts had been silently excluded, and 58 of them later turned out to be valid issues. That completely changed the way I think about AI-generated dashboards. We often celebrate a clean dashboard, but this post reminded me that sometimes the absence of alerts can be just as dangerous as the presence of them.
Another part I really appreciated was Alex's response when he was questioned about changing the threshold. He wasn't trying to prove he was right or make anyone look wrong—he simply wanted the system to stop hiding information that could actually matter. That small conversation at the end felt surprisingly realistic because in real projects, technical decisions are often as much about communication and trust as they are about code.
One more thing I liked was that the article didn't paint AI as either "good" or "bad." Instead, it highlighted something much more important: AI decisions are shaped by the rules we give it. If those rules filter out useful signals, the dashboard may look perfect while reality tells a different story. That's a subtle but powerful message.
Really well written. This is the kind of post that stays in your mind even after you've finished reading it.
And now... after making all of us question every green dashboard we see, I think you've earned a break. :D Go enjoy your Nintendo... I'll just open my old Nokia and play Snake while pretending my dashboard is 100% compliant too. 🐍
Honestly you read way more into it than I did while writing 😂 "Absence of alerts is more dangerous than presence" — that hit different coming from someone else.
The 1530 thing is semi-real btw — took it from an actual incident, just exaggerated a bit for the story 🤏. So yeah you're spot on about rules shaping output.
Anyway, it's the weekend — go relax, play some games (and I mean all kinds, not just video games). That's the important thing. 🎮🤣
@technogamerz Apologies for the wait — Stratagem #6 is finally out, so now I can get back to playing my Switch. 😂
Why are you apologizing to @technogamerz!! She doesn't even write posts!!