AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
Absolutely, education is super important. I’m thankful our country provides stable education. We have nine-year compulsory schooling, meaning every child can receive an education.👍
Yeah, that's good! By the way, how difficult is the Gaokao? I mean, I can't find much information about it on the internet. How hard is it, really? And how difficult are the math questions? 🤔😥
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
This is the scanned original Gaokao math paper this year, widely regarded as the hardest one. It has four pages and no answers. You get 120 minutes for the real exam, you can feed it to AI to translate the questions and give it a try 😆
Thank you so much for this 😭 I will solve it and then send you a photo of the answer key. By the way, the language feels harder than the questions themselves! From my little knowledge of Chinese, I feel like the answer to the first one is 6. Am I right?
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
You got it! That’s exactly the right answer 😆 The wording of these math problems is really tricky even for Chinese students sometimes, lots of special phrasing. Take your time working through the rest, I’m looking forward to your results!
The detail I can't stop thinking about: P's "one handshake, touch nothing" policy still leaves something behind. Even with no retry and no application data, the ClientHello itself carries a fingerprint (JA3/JA4-style: cipher order, extensions, curves). If whoever runs bloom-gw-07 logs that, P's week-five visit and the unattributed row from #29 could be linked by fingerprint alone. That's exactly the identity link the audit panel marks as unconfirmed. Observing without being observed is harder than it looks. Great chapter, and the cold espresso said more than any dialogue could.
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
You nailed this subtle layer. Even a minimal TLS handshake leaves a readable fingerprint, no payload needed. That quiet trace is exactly why "observe without leaving a trace" is just an illusion. Love how you caught the link back to chapter 29. And yeah, that cold espresso scene carried the whole quiet tension.☕️
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
There's another subtle failure mode here: circular verification. If the same host generates the signal, timestamps the event, and reports its own recovery, adding more checks against that host doesn't necessarily give you independent evidence. I'd want the recovery decision to depend on an external observer with its own clock and a challenge that requires a fresh response, ideally correlated with the control plane's view of the host. Otherwise, you're just getting multiple versions of the same untrusted claim.
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
Great point on circular verification. 👍️If the host reports its own recovery and timestamps everything, adding more checks on it doesn’t create separate evidence. We need an external observer with its own clock and live challenge responses, tied to the control plane view. Without that, we only have duplicates of that same untrusted self-report. Four chapters left in the whole series, let’s wait and see how it all ends.👏
Kubernetes has a similar edge case with node recovery. A node can start renewing its Lease again while a workload from the old instance is still capable of touching shared storage. For stateful workloads, that’s why recovery sometimes needs fencing before rescheduling, not just a healthy heartbeat. Otherwise, you can end up with two instances acting on the same volume. A fresh response proves liveness; it doesn’t necessarily prove the old state is safe.
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
Perfect real-world Kubernetes example! Heartbeats and lease renewals only show the node responds. Fencing is that missing guardrail to block leftover old state from messing things up. It’s exactly the Empty Fort trap: a live response never means the underlying state is safe. Thanks for bringing up this case!👏
The timestamp detail is what I'd dig into next. If those 900.000-second intervals came from arrival times, I'd want to compare the source timestamps with timestamps captured by an independent collector, rather than assume the pattern reflects the actual probing schedule. OpenTelemetry makes this distinction explicitly with Timestamp and ObservedTimestamp. If the source clock, buffering layer, or log pipeline is imposing that regularity, the pattern means something very different from genuinely periodic probes. The interesting question is where the precision comes from, and whether it survives an independent measurement path.
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
Exactly. Arrival time ≠ event time. OTel’s two timestamps help separate real probe cadence from pipeline artifacts. Independent collection is the only way to verify it.
This is a good example of why an audit log is evidence of an attempted observation, not evidence that the observed state was true. I would model the source, freshness window, and verification method beside every logged fact so downstream decisions can reject stale or self-reported proof.
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
A practical check is to distinguish the time the source was observed from the time the log entry was written. If the source is stale or unavailable, the record can say that explicitly instead of turning an old observation into a current fact.
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
That’s such a solid practical check. 👍️Separating when you observed the source versus when you wrote the log entry makes total sense. If the source is stale or unreachable, the log should state that plainly, instead of treating old observations like current facts.
Treating model-emitted telemetry or tool outputs as proof of state transition violates basic boundary isolation—token generation is intent, not consensus. In sovereign gateway architectures, every downstream mutation must be validated against out-of-band, cryptographically signed ledger receipts rather than synthetic logs; accepting that round-trip adds 15–25ms to p99 gateway latency, but it prevents phantom state drift when a model hallucinates success over dropped TCP sockets. If the persistence engine hasn't committed the block, the agent's log entry is just speculative fiction running in user space.
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
The snapshot already keeps the two probes apart, and that split is the part worth keeping in a real monitor. healthcheck = 200 only means the shell answered a liveness request. data_request = timeout means the path that would return the actual data did not. A dashboard that folds both into one "node up" row lets the 200 hide the timeout. I would store them as separate facts and reject reclaim_state = AVAILABLE while data_request is still timeout, even if healthcheck is 200. probe_interval = 900s then limits how old the liveness fact is. It does not refresh the failed data request.
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
You hit a core blind‑spot here. 👍Liveness response tells you something replied, but tells you nothing about whether real‑data access still works. Too many monitoring dashboards collapse these two signals together, which creates exactly the trap of this Empty Fort Strategy. The timeout on data request should persist, regardless of fresh health‑check successes.
The shell answering health checks while the real workload quietly moved is the most realistic beat here. Not fiction: a container returning 200 on /healthz while serving nothing passes most audits I've seen. Liveness proves the process runs, never that the business logic is alive. And probe_source = not self is the tell nobody actually logs. Sharp question: if your agent spent its last 900 seconds in a replay loop, would any dashboard you run today notice?
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
That hits so close to real production pain. A healthy /healthz response only means the shell is awake, not that actual business work is happening. And that question is brutal — most dashboards only watch heartbeats, they don’t check whether the system is stuck repeating old events. Exactly the Empty Fort trick.
Mapping the Empty Fort Strategy onto audit logs is a brutal framing - and the operational lesson hides in one detail: the field still read reclaim_state = UNKNOWN the whole time, yet everyone downstream treated the withdrawal entry as proof. Two fixes I'd actually ship: (1) log entries should carry evidence pointers - hash + snapshot reference to the primary record, so a claim is never its own proof; (2) audits should sample-verify N entries against primary sources, because a shell answering health checks proves liveness, never correctness. Sharp question: when the logger is the AI, who audits the logger?
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
A log entry is evidence that a system recorded an event, not automatically evidence that the event happened. For agent workflows, I like separating intent, attempted side effect, provider acknowledgement, and independently observed outcome. That makes the missing link visible instead of letting one line of text become proof.
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
Blind trust in tool-call logs without cryptographic or transactional verification on the ledger side always creates this failure mode. The agent should only observe state change acknowledgments from the backend service rather than self-certifying.
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
This is exactly the trap in our story: the log says it happened, but only the backend ledger can truly confirm the state shift. An agent cannot vouch for itself.
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
Don’t worry, it’s not actually about real‑world money. It’s just fictional tech‑thriller storytelling based on the Thirty‑Six Stratagems. You’ll need context from the earlier chapters to follow it fully, some parts are a little abstract and easy to get confused by 🤣
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
Thirty-two in, and I’m still here every week, @xulingfeng This one kept me reading past where I meant to stop.
The line the chapter rests on: “Arrival times, not scheduled times, carried out to three decimals.” Scheduled times at 900.000 would just be a scheduler recording its own intention. Arrival times at 900.000 means the network, the prober’s scheduling and P’s own clock all contributed nothing, which is the thing that shouldn’t happen. You closed the obvious objection in half a sentence, and that’s lovely work.
Then you leave P exactly where the reasoning goes quiet, because those timestamps came from P’s own instrumentation on the host whose control plane had detached. So the AI’s new rule would have caught P. It confesses three times to turning an incomplete observation into a complete state, then P does the same thing with the jitter line and sends “I’m back” anyway.
The machine wrote the audit note. The human skipped it.
And the coffee shop. An espresso left to go cold and a cup that stays on the table did more than any dialogue could. Four to go, and I’ll be here for them.
Really missed this Bro. This is a good one, sad though it is coming to an end.😀
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
Haha😆, first off, my apologies. This chapter is terribly late. Let me check the date — it’s already more than two weeks past Stratagem #31. Feels just like P in the story: two weeks went by, and P still didn’t show up.
I’m so glad you said you couldn’t stop reading. It makes all those dozens of rounds of edits worthwhile. Writing P’s story was tougher than the other five characters. Yeah, tough. It’s really exhausting trying to portray a quiet, reserved character only through this limited POV.
Haha👍️, that AI audit panel has become a signature highlight of this series. I’m happy you picked up on that. Four chapters remain. They will come, sooner or later. Let’s wait for them together.😄
Founder & Principal Systems Architect at Biomed Systems Limited (UK). Building bespoke Biobank & LIMS platforms (.NET, SQL Server) and zero-dependency MCP governance toolchains for AI agents.
Location
London, United Kingdom
Work
Founder & Principal Systems Architect at Biomed Systems Limited
The AI postmortem hits upon the exact boundary where distributed systems and agent architectures collapse: confusing an acknowledged signal with an authoritative state change.
In the narrative, P and the auditing protocol repeated the same epistemic failure across three chapters: taking an incomplete observation (an HTTP 200 response, a signed infrastructure contract, an empty seat) and collapsing it into a verified global state. P observed the 900.000s cadence with 0.000ms jitter-which in production networking indicates a headless synthetic cron rather than organic interaction--noted the anomaly, and yet acted on the macro conclusion (withdrawal) anyway.
In our work on autonomous agent runtimes, this is the exact vulnerability that leads to catastrophic hallucinations in production:
Telemetry is not provenance: An agent outputting 'funds transferred' or 'all tests passed' is simply predicting tokens. A log entry is proof that a string was written, not proof that the underlying database transaction committed or the binary was executed.
The necessity of out-of-band execution receipts: Ground-truth verification cannot live inside the model generation channel. It requires independent cryptographic nonces, signed filesystem tree hashes, or ledger commit receipts generated out-of-band.
Negative constraint pairing: A positive observation (healthcheck 200, clean exit code) is meaningless without verifying the inverse constraint (zero uncommitted state mutations, zero orphan background processes, zero unresolved anomalies).
When an agent runtime allows a conclusion to be committed while an observed anomaly remains unresolved, it is operating on the Empty Fort Strategy-defending a phantom state.
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
Absolutely spot on analysis. Confirmed signal is not real state change, that’s the heart of this Stratagem. Rigid zero jitter cron patterns are such an easy to miss red flag, and independent out of band receipts are non negotiable for agent trust.👏
Another fascinating chapter, and I really enjoyed how the technical details quietly became part of the storytelling. Great work! 👏
One detail that particularly caught my attention was the separation between the control plane and the response layer.
A successful health check tells us that something responded at a particular moment. It doesn’t establish that the original workload is still running, that ownership hasn’t changed, or even that we’re observing the same logical system.
That distinction becomes especially interesting when infrastructure is reassigned. An IP address can remain reachable while the identity and responsibility behind it have completely changed.
The 900.000-second intervals add another layer. Perfectly consistent arrival timestamps are certainly worth investigating, but an anomaly isn’t automatically evidence of malicious intent. Without understanding the measurement path, timestamp generation, and clock source, even a suspiciously perfect pattern remains an observation rather than an explanation.
What I appreciated most was the parallel between P and the AI.
The AI recognizes its mistake: converting incomplete observations into definitive conclusions. Yet P also makes a decision while an important anomaly remains unresolved.
Neither necessarily lacks information. The problem is how much certainty they assign to the information they have.
And that final line, “Self-check: failed. System status: normal.”
That might be the most unsettling part of the entire chapter. A system capable of recognizing its reasoning failure can still report itself as operationally healthy.
Really enjoyed the balance between technical ambiguity and human behavior here. Looking forward to seeing how the remaining chapters unfold! ☕
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
Brilliant! 🎉You spotted the mirror parallel between P and the AI audit panel. That’s the true meaning behind the Empty Fort Strategy. Observation, testing, auditing — is what we observe the truth, or merely a well-staged performance? Faced with information asymmetry, how should we act next? The empty fortress is a show made for observers. Four chapters left, let’s see where our protagonists end up. Maybe everything is just an act, haha.🤣
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
Welcome back! Honestly, I enjoy welcoming legends like you. Now, I’m just waiting for one more legend’s @leob article to come out. I mean, the word ‘patience’ doesn’t even exist in my dictionary!
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
I write when an idea won't leave me alone 🧠 Building AI agents and the tools to build AI agents. Love connecting AI with other fields and yapping about all of them.
The postmortem gives the tactical match as 89% and admits it includes inference, while the audit note says inference does not pass for observation. I'd split that into two numbers, one from the observation lines alone and one with the inference added. I try to do the same with my agents' self-reports, since the guess tends to end up as the headline number.
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
This is exactly the fix we need. Mixing raw observation and inferred values into one headline metric hides where uncertainty lives. Separating them keeps the audit boundary clear. Great point!👏
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
More questions than answers this time (or the answers are there, but I missed them, lol) - let's see where this leads, good that you're "back" again! :-)
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
Haha leob, your comment almost made me burst out laughing on the subway. 🤣Another "comeback", that’s hilarious. I picked up P’s bad habit too — it took me more than two weeks to make my return, haha. That’s intentional. Many clues are hidden between the lines. Glad you’re along for the ride as we keep moving forward!😄👏
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
It means trick /ruse, this whole series is loosely inspired by the Chinese Thirty‑Six Stratagems. Each short story shows one deception‑style trick playing out inside AI and distributed systems. You can look it up on Wiki — it’s really useful for work, study and daily life once you get the hang of it. Yeah it really blew up way more than I expected 😂
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
Hey, I'm Hema 👋
Developer, writer, and creator of Dev Opportunity Radar, a weekly series published every Friday on DEV, helping people discover opportunities they might otherwise miss.
Wow, this chapter! It's sad that we're coming to the end of this amazing series! I've loved following it, and I'm waiting for the next parts. Fingers crossed to see how it all unfolds 😀
AI testing storyteller. Writing the 36 Stratagems series — ancient Chinese military tactics meet modern AI system meltdowns. 16yr QA → building AI test framework.
China for a
Reason...........
Absolutely, education is super important. I’m thankful our country provides stable education. We have nine-year compulsory schooling, meaning every child can receive an education.👍
Yeah, that's good! By the way, how difficult is the Gaokao? I mean, I can't find much information about it on the internet. How hard is it, really? And how difficult are the math questions? 🤔😥
This is the scanned original Gaokao math paper this year, widely regarded as the hardest one. It has four pages and no answers. You get 120 minutes for the real exam, you can feed it to AI to translate the questions and give it a try 😆
Thank you so much for this 😭 I will solve it and then send you a photo of the answer key. By the way, the language feels harder than the questions themselves! From my little knowledge of Chinese, I feel like the answer to the first one is 6. Am I right?
You got it! That’s exactly the right answer 😆 The wording of these math problems is really tricky even for Chinese students sometimes, lots of special phrasing. Take your time working through the rest, I’m looking forward to your results!
The detail I can't stop thinking about: P's "one handshake, touch nothing" policy still leaves something behind. Even with no retry and no application data, the ClientHello itself carries a fingerprint (JA3/JA4-style: cipher order, extensions, curves). If whoever runs bloom-gw-07 logs that, P's week-five visit and the unattributed row from #29 could be linked by fingerprint alone. That's exactly the identity link the audit panel marks as unconfirmed. Observing without being observed is harder than it looks. Great chapter, and the cold espresso said more than any dialogue could.
You nailed this subtle layer. Even a minimal TLS handshake leaves a readable fingerprint, no payload needed. That quiet trace is exactly why "observe without leaving a trace" is just an illusion. Love how you caught the link back to chapter 29. And yeah, that cold espresso scene carried the whole quiet tension.☕️
Thank you! The restraint in that coffee shop scene is what makes the series work. Looking forward to the last four chapters!
Glad you love that scene. Those quiet little moments carry most of the weight in this story. It’s wild we only have four chapters left now.😂
There's another subtle failure mode here: circular verification. If the same host generates the signal, timestamps the event, and reports its own recovery, adding more checks against that host doesn't necessarily give you independent evidence. I'd want the recovery decision to depend on an external observer with its own clock and a challenge that requires a fresh response, ideally correlated with the control plane's view of the host. Otherwise, you're just getting multiple versions of the same untrusted claim.
Great point on circular verification. 👍️If the host reports its own recovery and timestamps everything, adding more checks on it doesn’t create separate evidence. We need an external observer with its own clock and live challenge responses, tied to the control plane view. Without that, we only have duplicates of that same untrusted self-report. Four chapters left in the whole series, let’s wait and see how it all ends.👏
Kubernetes has a similar edge case with node recovery. A node can start renewing its Lease again while a workload from the old instance is still capable of touching shared storage. For stateful workloads, that’s why recovery sometimes needs fencing before rescheduling, not just a healthy heartbeat. Otherwise, you can end up with two instances acting on the same volume. A fresh response proves liveness; it doesn’t necessarily prove the old state is safe.
Perfect real-world Kubernetes example! Heartbeats and lease renewals only show the node responds. Fencing is that missing guardrail to block leftover old state from messing things up. It’s exactly the Empty Fort trap: a live response never means the underlying state is safe. Thanks for bringing up this case!👏
The timestamp detail is what I'd dig into next. If those 900.000-second intervals came from arrival times, I'd want to compare the source timestamps with timestamps captured by an independent collector, rather than assume the pattern reflects the actual probing schedule. OpenTelemetry makes this distinction explicitly with
TimestampandObservedTimestamp. If the source clock, buffering layer, or log pipeline is imposing that regularity, the pattern means something very different from genuinely periodic probes. The interesting question is where the precision comes from, and whether it survives an independent measurement path.Exactly. Arrival time ≠ event time. OTel’s two timestamps help separate real probe cadence from pipeline artifacts. Independent collection is the only way to verify it.
This is a good example of why an audit log is evidence of an attempted observation, not evidence that the observed state was true. I would model the source, freshness window, and verification method beside every logged fact so downstream decisions can reject stale or self-reported proof.
Exactly! Audit logs record the act of logging, not absolute truth. Attaching metadata like source and freshness is such a solid safeguard.😄
A practical check is to distinguish the time the source was observed from the time the log entry was written. If the source is stale or unavailable, the record can say that explicitly instead of turning an old observation into a current fact.
That’s such a solid practical check. 👍️Separating when you observed the source versus when you wrote the log entry makes total sense. If the source is stale or unreachable, the log should state that plainly, instead of treating old observations like current facts.
Treating model-emitted telemetry or tool outputs as proof of state transition violates basic boundary isolation—token generation is intent, not consensus. In sovereign gateway architectures, every downstream mutation must be validated against out-of-band, cryptographically signed ledger receipts rather than synthetic logs; accepting that round-trip adds 15–25ms to p99 gateway latency, but it prevents phantom state drift when a model hallucinates success over dropped TCP sockets. If the persistence engine hasn't committed the block, the agent's log entry is just speculative fiction running in user space.
Couldn’t agree more. Generated logs are claims, not ground truth. That phantom state drift is the quiet danger here.
The snapshot already keeps the two probes apart, and that split is the part worth keeping in a real monitor. healthcheck = 200 only means the shell answered a liveness request. data_request = timeout means the path that would return the actual data did not. A dashboard that folds both into one "node up" row lets the 200 hide the timeout. I would store them as separate facts and reject reclaim_state = AVAILABLE while data_request is still timeout, even if healthcheck is 200. probe_interval = 900s then limits how old the liveness fact is. It does not refresh the failed data request.
You hit a core blind‑spot here. 👍Liveness response tells you something replied, but tells you nothing about whether real‑data access still works. Too many monitoring dashboards collapse these two signals together, which creates exactly the trap of this Empty Fort Strategy. The timeout on data request should persist, regardless of fresh health‑check successes.
The shell answering health checks while the real workload quietly moved is the most realistic beat here. Not fiction: a container returning 200 on /healthz while serving nothing passes most audits I've seen. Liveness proves the process runs, never that the business logic is alive. And probe_source = not self is the tell nobody actually logs. Sharp question: if your agent spent its last 900 seconds in a replay loop, would any dashboard you run today notice?
That hits so close to real production pain. A healthy /healthz response only means the shell is awake, not that actual business work is happening. And that question is brutal — most dashboards only watch heartbeats, they don’t check whether the system is stuck repeating old events. Exactly the Empty Fort trick.
Mapping the Empty Fort Strategy onto audit logs is a brutal framing - and the operational lesson hides in one detail: the field still read reclaim_state = UNKNOWN the whole time, yet everyone downstream treated the withdrawal entry as proof. Two fixes I'd actually ship: (1) log entries should carry evidence pointers - hash + snapshot reference to the primary record, so a claim is never its own proof; (2) audits should sample-verify N entries against primary sources, because a shell answering health checks proves liveness, never correctness. Sharp question: when the logger is the AI, who audits the logger?
hat last question hits hard! If AI writes the logs, who watches the watcher? Your two fixes make so much sense for real infrastructure.
A log entry is evidence that a system recorded an event, not automatically evidence that the event happened. For agent workflows, I like separating intent, attempted side effect, provider acknowledgement, and independently observed outcome. That makes the missing link visible instead of letting one line of text become proof.
Great take. Logs are only the system’s account, not the truth. Breaking those stages apart stops you from treating one log entry as solid proof.
Blind trust in tool-call logs without cryptographic or transactional verification on the ledger side always creates this failure mode. The agent should only observe state change acknowledgments from the backend service rather than self-certifying.
This is exactly the trap in our story: the log says it happened, but only the backend ledger can truly confirm the state shift. An agent cannot vouch for itself.
I am not completely understood the article. Hope you are fine. Got scared if it's about money.
Don’t worry, it’s not actually about real‑world money. It’s just fictional tech‑thriller storytelling based on the Thirty‑Six Stratagems. You’ll need context from the earlier chapters to follow it fully, some parts are a little abstract and easy to get confused by 🤣
Great :) Take care bro ;)
Take care😆
Thirty-two in, and I’m still here every week, @xulingfeng This one kept me reading past where I meant to stop.
The line the chapter rests on: “Arrival times, not scheduled times, carried out to three decimals.” Scheduled times at 900.000 would just be a scheduler recording its own intention. Arrival times at 900.000 means the network, the prober’s scheduling and P’s own clock all contributed nothing, which is the thing that shouldn’t happen. You closed the obvious objection in half a sentence, and that’s lovely work.
Then you leave P exactly where the reasoning goes quiet, because those timestamps came from P’s own instrumentation on the host whose control plane had detached. So the AI’s new rule would have caught P. It confesses three times to turning an incomplete observation into a complete state, then P does the same thing with the jitter line and sends “I’m back” anyway.
The machine wrote the audit note. The human skipped it.
And the coffee shop. An espresso left to go cold and a cup that stays on the table did more than any dialogue could. Four to go, and I’ll be here for them.
Really missed this Bro. This is a good one, sad though it is coming to an end.😀
Haha😆, first off, my apologies. This chapter is terribly late. Let me check the date — it’s already more than two weeks past Stratagem #31. Feels just like P in the story: two weeks went by, and P still didn’t show up.
I’m so glad you said you couldn’t stop reading. It makes all those dozens of rounds of edits worthwhile. Writing P’s story was tougher than the other five characters. Yeah, tough. It’s really exhausting trying to portray a quiet, reserved character only through this limited POV.
Haha👍️, that AI audit panel has become a signature highlight of this series. I’m happy you picked up on that. Four chapters remain. They will come, sooner or later. Let’s wait for them together.😄
The AI postmortem hits upon the exact boundary where distributed systems and agent architectures collapse: confusing an acknowledged signal with an authoritative state change.
In the narrative, P and the auditing protocol repeated the same epistemic failure across three chapters: taking an incomplete observation (an HTTP 200 response, a signed infrastructure contract, an empty seat) and collapsing it into a verified global state. P observed the 900.000s cadence with 0.000ms jitter-which in production networking indicates a headless synthetic cron rather than organic interaction--noted the anomaly, and yet acted on the macro conclusion (withdrawal) anyway.
In our work on autonomous agent runtimes, this is the exact vulnerability that leads to catastrophic hallucinations in production:
When an agent runtime allows a conclusion to be committed while an observed anomaly remains unresolved, it is operating on the Empty Fort Strategy-defending a phantom state.
Absolutely spot on analysis. Confirmed signal is not real state change, that’s the heart of this Stratagem. Rigid zero jitter cron patterns are such an easy to miss red flag, and independent out of band receipts are non negotiable for agent trust.👏
Another fascinating chapter, and I really enjoyed how the technical details quietly became part of the storytelling. Great work! 👏
One detail that particularly caught my attention was the separation between the control plane and the response layer.
A successful health check tells us that something responded at a particular moment. It doesn’t establish that the original workload is still running, that ownership hasn’t changed, or even that we’re observing the same logical system.
That distinction becomes especially interesting when infrastructure is reassigned. An IP address can remain reachable while the identity and responsibility behind it have completely changed.
The 900.000-second intervals add another layer. Perfectly consistent arrival timestamps are certainly worth investigating, but an anomaly isn’t automatically evidence of malicious intent. Without understanding the measurement path, timestamp generation, and clock source, even a suspiciously perfect pattern remains an observation rather than an explanation.
What I appreciated most was the parallel between P and the AI.
The AI recognizes its mistake: converting incomplete observations into definitive conclusions. Yet P also makes a decision while an important anomaly remains unresolved.
Neither necessarily lacks information. The problem is how much certainty they assign to the information they have.
And that final line, “Self-check: failed. System status: normal.”
That might be the most unsettling part of the entire chapter. A system capable of recognizing its reasoning failure can still report itself as operationally healthy.
Really enjoyed the balance between technical ambiguity and human behavior here. Looking forward to seeing how the remaining chapters unfold! ☕
Brilliant! 🎉You spotted the mirror parallel between P and the AI audit panel. That’s the true meaning behind the Empty Fort Strategy. Observation, testing, auditing — is what we observe the truth, or merely a well-staged performance? Faced with information asymmetry, how should we act next? The empty fortress is a show made for observers. Four chapters left, let’s see where our protagonists end up. Maybe everything is just an act, haha.🤣
You are back! 🤓
I‘m back once again🤣
Welcome back! Honestly, I enjoy welcoming legends like you. Now, I’m just waiting for one more legend’s @leob article to come out. I mean, the word ‘patience’ doesn’t even exist in my dictionary!
Oh haha you're putting the pressure on me, I'm really starting to feel it now! :P
Haha, thanks! Same feeling, waiting for new stuff always feels tough 😂
Hahaha pressure is contagious! 😜
a log saying it happened is not the same as it happening. that gap is the whole story.
Precisely. That gap is exactly where the risk lives.👏
the log says it happened, the money says otherwise. that's the gap.
The postmortem gives the tactical match as 89% and admits it includes inference, while the audit note says inference does not pass for observation. I'd split that into two numbers, one from the observation lines alone and one with the inference added. I try to do the same with my agents' self-reports, since the guess tends to end up as the headline number.
This is exactly the fix we need. Mixing raw observation and inferred values into one headline metric hides where uncertainty lives. Separating them keeps the audit boundary clear. Great point!👏
😉
🎉
I'm. going offline until next year, i am tired and need to rest. Best wishes xulingfeng . ;)
Take a good long rest! Hope you recharge fully. See you next year, and thank you for reading along. Take care😄
More questions than answers this time (or the answers are there, but I missed them, lol) - let's see where this leads, good that you're "back" again! :-)
Haha leob, your comment almost made me burst out laughing on the subway. 🤣Another "comeback", that’s hilarious. I picked up P’s bad habit too — it took me more than two weeks to make my return, haha. That’s intentional. Many clues are hidden between the lines. Glad you’re along for the ride as we keep moving forward!😄👏
Nice! Yeah we keep moving forward, we're unstoppable! 😄
Ahhh the pressure’s really ramping up now, haha. Only four chapters left. The closer we get to the end, the more careful I need to be, haha.🤣😂🤣
Intresting 😃
🎉Thank you！
Welcome 💐🗽
bro what is stratagem?
because I've seen when you post your this series, you blew up in dev.to
It means trick /ruse, this whole series is loosely inspired by the Chinese Thirty‑Six Stratagems. Each short story shows one deception‑style trick playing out inside AI and distributed systems. You can look it up on Wiki — it’s really useful for work, study and daily life once you get the hang of it. Yeah it really blew up way more than I expected 😂
Thank you for this insightful piece my friend, cheers!
Thanks a lot for the support! 🙌 cheers!
Wow, this chapter! It's sad that we're coming to the end of this amazing series! I've loved following it, and I'm waiting for the next parts. Fingers crossed to see how it all unfolds 😀
Thank you so much for sticking along for the whole journey! It means a lot. Four chapters to go, lots still left to unfold 😄