Deceive the enemy with an obvious approach that will take a very long time, while ambushing them with another approach.
— The 36 Stratagems, Openly Repair the Gallery Roads, But Sneak Through the Passage of Chencang
Alex opened the training laptop. Typed a command. The screen returned one line of output. He didn't explain what it meant — no one in the room asked.
Page 37 of Alex's hardcover notebook still carried a number from his last job: 847×37%. That was Axon's claim — 847 tickets processed daily. What the number left out: 37% of those tickets ended up with a human anyway. The AI picked off the tasks it recognized. Everything else landed on someone at 3 AM.
He brought that note with him to MedTech.
Six months later, MedTech signed a seven-figure AI operations monitoring contract. The vendor promised full-stack coverage. AI-driven. Real-time learning. The CIO's all-hands email read: "This dashboard covers everything. No blind spots."
At the vendor demo, Alex saw a page layout that was new and familiar at the same time. His brain, without asking, overlaid the confidence-filtering module in the config panel onto Axon's old dashboard. Different logo. Same design pattern: set a threshold, suppress anything below it. Not absent — hidden.
He thought of the number on page 37.
He said nothing.
Training
MedTech's CIO set the tone: full migration to the new dashboard. Existing monitoring tools to be phased out.
Alex was named training lead. The reason was straightforward: Principal Architect. He knew MedTech's systems better than anyone. The CIO's email said — "Alex will lead the transition and ensure a smooth rollout."
Day one. The projector showed the new dashboard's home screen. AI-generated system topology. Real-time anomaly scores. Trend prediction curves. A line of small text sat at the top: Anomalies displayed at confidence ≥ 70%.
"The dashboard evaluates anomaly confidence in real time." Alex opened the config page. "Anything below the threshold gets routed to the low-priority queue."
He ran a boundary test — a historical false-positive sample from a specific routing pattern. The dashboard calculated for three seconds and returned: "Confidence 63% — below threshold. Filtered."
The raw JSON flashed on the screen for a moment before the next slide covered it. But Alex saw it:
{
"event_id": "evt_2a3f8c",
"confidence": 0.63,
"threshold": 0.70,
"classification": "low_priority",
"model_version": "v2.1.4",
"feature_bucket": "routing_anomaly",
"training_set_coverage": false
}
"See? It says this isn't an anomaly." Alex closed the window.
Twenty people sat in the room. Some took notes. Some checked their phones. No one asked a question. Alex flipped to the next slide.
Three days later, second training session. He used the same routing pattern again.
"Alex." An engineer in the back row looked up from his notes. "You demoed the same routing config last time. Both times it came back 63%."
"Did I?" Alex said. He turned to the next slide. Paused. Turned back.
"Same config. Two tests. Both at 63%," the engineer said. "What does that mean? Is the threshold too high, or is it actually not an anomaly?"
Alex looked at the engineer. He had the answer — 63% twice wasn't a coincidence. It meant the dashboard's confidence ceiling for that routing pattern sat at 63%. It would never reach the 70% display threshold. But he couldn't say that. Saying it meant explaining how he knew. It meant explaining that he'd seen the exact same pattern at Axon.
"Keep training." Alex said.
He flipped to the next slide. The engineer didn't push further. But Alex knew the exchange would stick.
Training ran two weeks. Alex showed up prepared every session — slides, hands-on demos, Q&A. Management was pleased: 100% attendance. Post-training feedback: 4.7 out of 5. "Finally, someone who actually knows how to use this thing," the CIO said at the weekly meeting.
No one noticed the pages Alex opened during breaks had nothing to do with the training material. His notebook gained a new entry:
Anomaly types in dashboard training set: 14
Known anomaly types in production: ≥ 23
Confidence threshold (default): 0.7
Same (Axon): 0.85
He drew a line across the same page. Above the line: the training schedule. Below the line: an architecture sketch with no title. Not the dashboard's network topology. An arrow from the production data stream to a small server, passing through a filter rule that appeared in no documentation anywhere.
The sketch stayed tucked inside the training materials. No one ever flipped to that page.
Infrastructure Change
Week two. Alex submitted an infrastructure change request through MedTech's IT service management system.
change_type: environment_extension
title: "Training environment expansion — mirror data pipeline needed for hands-on labs"
description: >
Training course entering hands-on phase. Students need to
experience real dashboard data flows in an isolated environment.
Requires one compute node, data copy pipeline configuration,
mapping a subset of production metrics.
approval_required: false
routing: principal_level
MedTech's change approval policy: infrastructure changes submitted by Principal-level engineers, with no cross-security-domain privilege escalation, auto-approve within 48 hours.
The change cleared at hour 31.
Alex got a small server. He spent one evening setting up the "training data copy pipeline." In the log collector config file, he added one extra output target: duplicate the raw production log stream heading to the AI dashboard into a local directory. Not the AI-processed, filtered, confidence-tagged logs. The raw ones. HTTP status codes. Response times. Database query durations. Error stack traces. Nothing filtered.
The config description said "Training environment isolated routing."
Over the next two weeks, Alex built a second dashboard. No AI. No confidence filtering. No pretty UI. A raw monitoring board — real-time data tables, error logs sorted by timestamp, a set of basic aggregate metrics. It was ugly. But it was complete. It showed what the AI dashboard showed, and it showed what the AI dashboard filtered out.
He told no one.
Silence
The day training ended, an email hit everyone's inbox: AI monitoring dashboard is now live. All teams switch to the new dashboard.
Old monitoring systems began their shutdown sequence one by one. Alex signed off on the cutover checklist.
His backup dashboard kept running. He set a daily alarm: 2:00 AM. Check.
Week one after the dashboard went live: 5.2% gap. The AI dashboard reported 97.1% coverage. The backup showed 91.9%.
Week two: 10.2%. AI dashboard: 97.0%. Backup: 86.8%.
Every morning, Alex arrived at his desk. Opened the backup dashboard. Glanced at it. Opened the AI dashboard. Glanced at it.
He logged the weekly gaps in his notebook. Drew a line under the new numbers:
Week 1: 5.2%
Week 2: 10.2%
Closed the notebook. Started his day. No one noticed.
Broken Bridge
Tuesday afternoon, week three. The AI dashboard pushed a model update. Release notes: "Optimized feature extraction pipeline performance."
Twenty-three minutes after deployment, the dashboard's data pipeline clogged. No alert fired — the pipeline blockage detection threshold fell within the model management scope, and the model had just updated, confidence not yet stabilized.
Sixty-three minutes later, ops took the first user report: "The dashboard data doesn't seem to be moving."
The emergency meeting assembled. The ops lead walked through the investigation: started with infrastructure — infrastructure monitoring showed normal server load. CPU and memory curves: flat lines. APM tools reported application latency within baseline. No anomalous network throughput.
But none of those tools covered the dashboard's metric layer. Model confidence distribution. Alert coverage rate. Feature drift rate. Outside the scope of traditional monitoring tools. The dashboard had been sold as "single-pane coverage." Teams had been trained to look at the dashboard first. Dashboard had a problem? Look at underlying systems. But the underlying tools had no visibility into the dashboard's data layer.
It took them 40 minutes to confirm one fact: the dashboard was showing a 6-hour-old snapshot. The pipeline had clogged. The dashboard hadn't stopped working — it kept displaying the last successful refresh. No timestamp alert. No visual indicator that the data had stalled. The dashboard looked like it was running fine. The data was just old.
Mike called the full group: "Who can see current real-time production status?"
No one answered. Ops reported on the infrastructure layer. Security confirmed network and permissions. But the real-time running state of production systems? — everyone had been looking at the AI dashboard for that answer. And the dashboard wasn't giving answers.
"Our —" Mike scanned the room. "— any monitoring we still have. Can it tell me what's happening right now?"
Silence.
Alex waited two seconds.
"I've got a training-environment monitor —" he said. "Still running. Might show something."
He opened his laptop. Connected to the small server. The raw monitoring board lit up — live data. He put it on the projector. No AI curves. No confidence labels. Just a table:
06-30 14:02:17 | POST /api/v1/orders | 200 | 47ms
06-30 14:02:18 | POST /api/v1/orders | 200 | 52ms
06-30 14:02:19 | POST /api/v1/orders | 503 | 3021ms
06-30 14:02:19 | POST /api/v1/orders | 200 | 44ms
06-30 14:02:20 | POST /api/v1/orders | 503 | 2876ms
06-30 14:02:21 | POST /api/v1/orders | 503 | 3401ms
06-30 14:02:22 | POST /api/v1/orders | 503 | 4123ms
Consecutive 503s piling up from 14:02:19 — not a single one flagged by the AI dashboard.
Ops used the information to trace the root cause: the model update's data pipeline change had broken the connection.
Six hours after the dashboard freeze was discovered, it came back. The vendor's postmortem report read: "Root cause: data pipeline configuration change — version incompatibility. Rolled back."
The meeting ended. People filed out. Mike stayed in his chair.
"When did you build that?" he asked.
"Training environment." Alex said. "Threw it together. Got lucky with the routing."
Mike didn't move. "Alex, you knew the dashboard would break. From day one. Didn't you?"
Alex said nothing.
"That 63% route," Mike said. "You tested it twice. First time was a test. Second time was confirmation. You never trusted this dashboard. Not from the start."
"I trust it to do what it was trained to do." Alex said.
"And the part it doesn't do?"
Alex was quiet for a few seconds. "That's not its job."
His fingers stopped on the edge of the keyboard for one second.
"Whose job is it, then?"
Alex didn't answer. Mike watched him close the laptop. He knew Alex wouldn't say more. But he also knew Alex already had.
By the time Alex walked out of the conference room, the config rule for the log collector had been archived. The record wasn't caught by the log collector. But a certain pair of eyes saw it.
The Third Cup
That night, Alex passed The Third Cup. He hesitated at the door — one leg already pointed in a different direction, frozen mid-step — then walked in.
The person behind the bar glanced at him. Set a ceramic coaster on the counter. Same spot as last time. Not an inch off.
"Not in a rush this time?"
Alex sat down at the bar. "No."
Coffee arrived. He took a sip. Set the cup down. The person behind the bar didn't leave. Didn't ask. After a few seconds, turned and wiped a glass that was already clean.
Alex finished. Set down the coaster. Left.
This is Openly Repair the Gallery Roads, But Sneak Through the Passage of Chencang — build a project everyone can see, and walk a completely different path in its shadow.
🤖 AI Post-Mortem
[36 Stratagems Tactical Database v3.1] Loaded
[Tactic Match] Openly Repair the Gallery Roads, But Sneak Through the Passage of Chencang
[Analysis Mode] Full-field scan
━━━━━━━━━━━━━━━━━━━━
Tactic Match: ~92%
Operator: Alex
Action: Built a backup monitoring system under the cover of AI dashboard training, within everyone's line of sight
Objective: Establish a production observability channel independent of the AI dashboard
Result: Backup channel was the only functioning monitor during dashboard failure
Attention Drift Mirror:
- Open repair (Training): Org-wide training sessions. 100% attendance. 4.7/5.0 feedback.
- Chencang passage (Backup): Infrastructure change request filed under training environment. Line 8 of config: data copy pipeline.
- Cognitive binding: Everyone bound Alex's name to "training lead." No one checked what the training server was actually running.
Counter-Detection Analysis:
- Strategy risk: Backup dashboard might remain undiscovered if panel never fails or never updates. Discovery probability: low.
- Info asymmetry mirror: Alex hiding backup dashboard vs AI dashboard hiding filtered anomalies. Mirror symmetry: high.
- Method/tool limits: Traditional infrastructure monitoring does not cover AI-dashboard-specific metric layers.
- External signal: Config rule left a record in audit logs. Audit agent: non-human. Traceability: yes.
Core Insights:
- AI dashboard blind spots: training boundary limitations. Not a technical malfunction.
- Hidden cost: not measured. not fixed.
- **System safety assessment: a backup channel that exists without being needed > needing a backup channel that doesn't exist.**
Next stratagem: Watch the fires burning across the river
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 (23)
The part that lifts this above a cautionary tale is the direction of the filter. Dropping anomalies below 70% confidence doesn't just hide problems, it hides the exact class of problem you kept a human around for. A failure the model was trained on arrives as a confident red flag. A genuinely novel one, the failure nobody has seen yet, has no reason to announce itself as a high-confidence anomaly. It can read as low confidence, or worse, as confidently normal, because the model has no template for it. Either way the 70% gate is precisely the wrong filter for the case that most needs a person, so the dashboard isn't blind by accident, it's blind in the direction of everything still unknown.
And what turns that into an organizational blind spot is silence. A monitor that filters quietly converts 'I don't know' into 'all clear,' and a suppressed count you cannot see is indistinguishable from a healthy zero. Which is why I'd read Alex's backup less as a clever stratagem and more as a bug report he couldn't file. If the dashboard had been made to declare its own suppression, one line, 'N events dropped below threshold, raw count here,' the keys would never have needed to go under the table. The defect was never that it filtered, every monitor filters. It's that it filtered without admitting it did. A monitor whose silence could mean either healthy or blind hasn't informed you, it's only made you feel informed, and that is the more expensive of the two.
You said it better than I did. The 70% gate being backwards for novelty, silence turning "I don't know" into "all clear" — that's not a side effect. That's the whole thing.
"Alex's backup as a bug report he couldn't file" — probably the truest read of that scene. He wrote the line the dashboard should have shipped with: N events dropped below threshold, raw count here.
Question I keep turning over: is the confidence-threshold problem baked in? If you assume every future failure will look like past ones, 70% works fine. But that assumption is the whole genre. Is there a statistical framing that treats low confidence not as noise but as a different kind of signal worth surfacing differently? Or does any monitor that thresholds just inherit this blind spot permanently?
The framing exists, and it starts by admitting that 'confidence' is two different quantities wearing one number. There's the uncertainty that comes from genuinely ambiguous input, noise, a coin that is actually fair, and there's the uncertainty that comes from the model being off its own map, an input unlike anything it trained on. Aleatoric and epistemic. A softmax score blends them, which is exactly why 70% cannot tell 'this is a hard call' from 'I have never seen this.' The novel failure lives entirely in the second kind, and the second kind is the one a single confidence number is worst at reporting.
So a thresholding monitor doesn't have to inherit the blind spot, but only if it stops thresholding the recognition score and adds an axis that is actually defined over the unknown. Two families do this. Novelty and OOD detection score how far an input sits from the training distribution (reconstruction error, distance in feature space, energy), and that score grows for the unseen instead of shrinking, so you escalate on it rather than filter on it. Conformal prediction is the other one: instead of a point confidence it returns a prediction set with a coverage guarantee. That guarantee assumes exchangeability and frays under the shift we are worried about, but the set still blows up or goes empty when the model is out of its depth. A fat or empty set is a first-class 'I don't know' that is statistically distinguishable from a confident answer, which is the 'surface it differently' you are reaching for.
Where your instinct is right: a monitor that thresholds a single in-distribution confidence inherits the blind spot permanently, because that number is not even defined over the space of things the model cannot recognize. You are measuring the known and reading its silence as coverage of the unknown. The fix is not fewer thresholds, it is a second threshold on a signal built for novelty. And even that never fully closes, a patient enough novel failure can be shaped to look in-distribution to the OOD detector too. Which is the same ending as before: the monitor's real job is not to be complete, it is to declare its own coverage on both axes and never pretend the silence on either one means healthy.
Aleatoric and epistemic wearing the same number — that's the whole thing in one sentence. Explains why 70% fails and why tweaking the threshold won't fix it.
The OOD detection axis sounds like the second panel Alex should have added. But the real point is your last paragraph: the monitor has to admit where it's blind on both axes. Can't let silence pretend everything's fine. That should ship in every monitoring product's docs.
One thing I keep wondering — when a conformal prediction set blows up or goes empty, does anyone actually surface that as "I don't know" to the operator? Or does it end up in a log nobody reads, same as the 1,530 filtered events? The technical fix might exist. The organizational one — someone has to look at an empty set — I haven't seen yet.😄
The empty set and the 1,530 filtered events die the same death, and it is not the log, it is that neither one has an owner who pays when it is ignored. A signal gets looked at exactly when someone is on the hook for not looking, and 'I don't know' by default is on no one's hook. So the organizational fix is not 'surface it,' surfacing is cheap and the operator's attention is the scarce resource. The fix is to attach a cost to ignoring it.
Concretely, the abstention has to do something other than get written down. It blocks: an empty set halts the pipeline or drops to a safe default and routes the case to a human queue with a name on it, so ignoring it now costs a stalled job instead of nothing. Or it is budgeted: the rate of 'I don't know' becomes a tracked SLO with a threshold, and a rising abstention rate pages someone the way an error budget does. A log line is the one design that guarantees no one looks, because it is the only one where looking stays optional.
And here is the part that should bother you, because it bothered me: the log nobody reads is the same bug we started with, moved up one floor. The model turned 'I don't know' into a silent zero. The org takes the model's honest 'I don't know' and turns it back into a silent zero by filing it where no one is accountable. Same suppression, wetware instead of software. Which is why the organizational fix is rarer than the technical one: producing the empty set is engineering, but making someone pay for ignoring it means admitting on the record that the system can be wrong, and that is expensive to sign your name to. Until the 'I don't know' blocks something or pages someone, it is a confession filed where confessions go to die.
The part about the same bug running on wetware instead of software — that one hits close to home.
We see it all the time in QA. A test suite runs, passes, report gets logged. Everyone moves on. The test was technically correct — it tested what it said it would test. But the thing it didn't test? That doesn't show up anywhere. No owner, no cost, no consequence. Same suppression, just wearing a green checkmark instead of a log line.
The signature problem you mentioned — "admitting on the record that the system can be wrong" — that's the real bottleneck. Not the engineering. Getting someone to sign their name to an 'I don't know' threshold means they own the miss when it happens. Most orgs would rather keep the miss invisible and deal with it when it surfaces as a production incident. At least then the blame has a clear target.
The incident is preferred for a reason that is perfectly rational and completely backwards: it trades a certain small cost now for a diffuse deferrable one later. Signing an 'I don't know' threshold makes you the owner of a miss that has not happened yet, on a probability, in front of everyone, today. The production incident makes the same miss concrete but relocates it, to the moment, to whoever was on call, to 'unforeseeable.' Same total damage, but the blame moves off the person who could have flagged it and onto circumstance. Individually rational, systemically worst, which is the signature of every incentive worth fixing.
And your QA case is the sharper version of mine, because a green checkmark is worse than a log line. The log line is passive suppression, nobody looks. The green checkmark is active suppression, it tells you to stop looking. Coverage that reports 100% green while the dangerous path simply is not in the suite does not just fail to inform you, it manufactures confidence against the exact spot that will hurt you. The honest suite has to ship its own gaps as first-class output, here is what I did not test, the same way the monitor declares its suppression. Otherwise the green check is the silent zero with a bow on it.
You are right that the signature is the real bottleneck and that no amount of engineering reaches it, and I would only add the one lever that does. The problem is that we ask an individual to sign each 'I don't know,' which is a personal confession. Move the signature up: make abstention a pre-blessed institutional policy, 'we do not ship below coverage X, we route it,' signed once by the org, not by the engineer at 2am. Then the flag is compliance, not confession, and the person raising it is following a rule instead of owning a miss. That is the only version I have seen make 'I don't know' safe to say, because it takes the blame off the one who is honest and puts it on the institution that set the bar, which is where it belongs.
That green checkmark point is the one I keep coming back to. I've seen coverage reports that said 94% — turned out 90% of it was auto-generated unit tests for getters and setters. The core logic wasn't in the suite. Green everywhere. Production outage in week two.
Your institutional policy fix — signed once by the org — makes sense in theory. I just haven't seen it work in practice. The org that signs the policy is rarely the same org that feels the delay when abstention blocks a shipment.
You just found the same bug a third time, and it is the one that has been under all of it. The log nobody reads, the green check that says stop looking, and the policy signed by people who never feel the delay are one failure: the person who benefits from suppressing is not the person who pays when it is wrong. My institutional fix does not escape that, it just relocates it, exactly as you say. A governance body that signs "we abstain below X" and never eats the week-two outage has written a log line on letterhead.
So the signature alone was never the lever. The lever is collapsing the two desks into one: the abstention threshold has to be owned by whoever also owns the incident, not by whoever owns the process. When the person who can waive the block is the same person whose oncall eats the outage that block would have prevented, they are trading delay against outage on one ledger, and they hold the line because overriding it now shows up as their own future page, not someone else's. Concretely that means the abstention lives in the same error budget the shipment pressure lives in, debited from one owner, not two orgs. Wherever "who decides to suppress" and "who pays for the miss" sit on different desks, the honest signal dies, and it does not matter whether it is a log, a checkmark, or a policy. The fix is the move you have been circling the whole time: put the decision and the consequence back on one desk.
I like how the stories keep coming back to the same theme from different angles: good-looking dashboards and impressive metrics don't replace understanding the system underneath. Alex quietly building a fallback while everyone focused on the shiny AI dashboard was a nice touch. Looking forward to the next one!
Glad these two landed the same way for you — they're different stories but the same thread: if you can't read what's under the metric, the metric is just decoration. Alex's fallback was exactly that — reading the room while everyone else read the dashboard. #9 is the same idea from a new angle, coming right up.
The real failure here isn't the 70% threshold, it's that the metadata telling you the threshold is wrong was sitting in the raw JSON the whole time.
training_set_coverage: falseandfeature_bucket: routing_anomalynever made it into the UI. A confidence filter that hides low-confidence events removes the operator's ability to even notice the blind spot, which is worse than a model that's merely inaccurate.The only durable fix is an audit log that lives outside the dashboard's filter. If "no blind spots" is the claim, someone has to be able to query what got suppressed and why, independent of the threshold the UI is showing. Otherwise it's a promise nobody can verify. Do the low-priority events you route actually get reviewed by anyone, or do they just accumulate until a 2am incident forces someone to dig them out?
You got it. That JSON flash — training_set_coverage: false — was on screen for maybe a second before Alex closed the window. He saw it. Everyone in the room could've. Then the next slide came up.
Your question about whether anyone actually reviews the low-priority events — in this story, nope. Not until the dashboard froze and the 503s piled up. That's the whole MedTech pattern: hide it now, find it later, 2 AM.
The keys under the table? That was Alex's audit log. Line 8 of his log collector config — duplicate the raw stream, build the second board. No AI thresholds attached. Ugly, but complete. He just had to ship it as "training environment" because nobody budgeted for a production audit trail. Which is exactly what you said: if you claim no blind spots, someone needs to be able to query what got suppressed.
Been turning this over — should vendors ship this audit layer as a standard thing? Or does every team have to roll their own, since the incentive to surface suppression isn't exactly in the vendor's business model?
Keeping the keys outside the dashboard is the part many AI control panels miss. A dashboard can coordinate work, but it should not become the root of trust for every action it approves. The more powerful the agent, the more important it is that authority and observability are not collapsed into one surface.
Nice one, there are quite a few points to take away - I thought this was one of them:
"Don't burn your trustworthy old bridges before you know whether your shiny new ones are good enough ..."
And, on a related note: companies falling into the trap of buying those shiny new toys without actually understanding how they work (and then insisting on shutting down their "old" stuff) ...
But the coolest part (I thought) was that Alex made them believe that the old monitoring system was gone, while he secretly still ran it under the guise of "training", and was able to use it to save their *sses when their shiny new dashboard dropped the ball ;-)
This must be some sort of 'system glitch' - zero likes on my comment, I've never seen that, because (as far as I know) dev.to always puts one "auto like" on every comment - right?
This must be a dev.to bug indeed — your two comments only showed up for me now. I was wondering yesterday why I hadn't seen your comment on this one, haha. Seeing your comment made my day. 😄
Haha nice to hear - yeah it must be that my comment made it into their database, but somehow (rare glitch) did not get picked up by whatever batch job(s) they run new comments through - the absence of that single "auto like" kind of proves it ;-)
P.S. and you liked my original comment, but it got just 1 like coz the auto-like is missing - compensated or that my liking my own comment ;-) ;-) ;-)
Great article! I found the section on (specific topic) particularly interesting because it connects well with real-world applications. Thanks for sharing your insights—I’m looking forward to reading more from you.
Sorry for reading this so late—I’ve been unwell for some time and only just got around to it.
This isn’t just a story about AI or dashboards; it’s a story about human judgment and responsibility. Alex didn’t keep a backup because he distrusted AI—he kept it because he understood that no system is infallible. The moment we stop questioning technology and surrender our critical thinking, we create our biggest vulnerability. The most resilient organizations aren’t the ones with the smartest AI—they’re the ones that never lose human oversight. Deep, thought-provoking, and brilliantly written.
See you in August bye 👋🏻
It's never too late to read.
Glad you're feeling better — no rush, your health comes first. "The moment we stop questioning technology and surrender our critical thinking" — that line's going to stick with me.
Take care of yourself. See you in August. 👋 By then the 36 Stratagems series should be well past the halfway mark — plenty to read when you're ready.
Yaah! Sure! ❤️