DEV Community: xulingfeng

Stratagems #33: Mark Reviewed an AI Method. The Reviewer Brought Back a Different Question.

xulingfeng — Fri, 13 Nov 2026 10:16:04 +0000

Doubt within doubt. Work from within, without losing your own footing.
— The 36 Stratagems, Turn the Enemy's Spy

Previously on this series:

#19: Mark Found His AI Audit Method in a Training Manual. He Left a Trap in His Report. "Entry's gone. Two weeks. Don't reach out. I'll find you."

#21: The AI Thought P Was Still Alive. P Was Already Gone. The entry became a shell. P fed it data and moved the real thing to another segment.

#31: Lena Took the Seat. Five conditions. Forty minutes. Zero friction.

#32: The AI Logged a Withdrawal. P Took It as Proof. One conclusion, one unexplained anomaly. The message went out before the anomaly was resolved.

The Old Snapshot

A garbage truck stopped below the window. Its reversing alarm sounded through the glass. An unfinished client report lay across Mark's desk. When his consulting inbox chimed, he pushed the report aside and opened his messages with P.

The two words from the night before were still on the screen.

I'm back.

He replied: “What can you send me?”

Forty minutes later, an encrypted email arrived from P. The attachments contained an index of seven handover documents, a status snapshot saved before the observation port had been shut down, and arrival times for twenty-two probes. There were no access credentials. P had added a note: keep the original records intact. Nothing after that point had been checked.

Mark decrypted the attachments and opened the snapshot. The save time appeared at the top.

# offline snapshot / before observation-port shutdown
healthcheck    = 200
probe_source   = 10.44.8.6  # not self
control_plane  = detached
data_request   = timeout
reclaim_state  = UNKNOWN

He emailed P: “Is the old endpoint still there?”

“Haven't connected again.”

“Are these scheduled send times or actual arrival times?”

“Actual arrivals. Decimal places untouched.”

Mark saved a separate copy as arrival_seconds.txt, one probe per line, with the times in seconds and the original decimal precision preserved. He made the copy read-only and calculated the gaps locally.

from decimal import Decimal
from pathlib import Path

rows = Path("arrival_seconds.txt").read_text().splitlines()
times = [Decimal(row.strip()) for row in rows if row.strip()]
assert len(times) == 22
assert all(t.is_finite() for t in times)
assert all(b > a for a, b in zip(times, times[1:]))
deltas = [b - a for a, b in zip(times, times[1:])]
print("checks:", len(times), "intervals:", len(deltas))
print("unique_seconds:", sorted(set(deltas)))

checks: 22 intervals: 21
unique_seconds: [Decimal('900.000')]

He scrolled to the bottom of the input file and checked the result again. Twenty-two arrivals. Twenty-one intervals. No second value.

The truck pulled away, its tires running through the water at the curb. Mark saved the result and added two entries beside it.

probe_source_owner: unverified
after_shutdown: no records supplied

“Identical intervals. Who's sending them?” he messaged P.

“Still can't confirm.”

He left the entry unverified. The seven handover documents predated the address allocation update, but another record P had flagged still listed the same rack as vacant. The effective dates had not been reconciled.

P sent another message. “Need anything else?”

“Keep the originals. Don't reconnect.”

Mark saved the calculation under old_snapshot, with the handover index in a separate folder.

The Email

Two days after P's email, a new message reached the consulting inbox. The subject was “Technical Confirmation of Methodology.” Mark expanded the recipient list, then read down.

The sender's signature appeared below the attachment notes.

Caleb Harris.

The cursor stopped over the name. A breeze lifted a corner of the client report. Mark held it down without scrolling. After a while, he opened the attachment. There was no greeting, just a review scope, proposed meeting times, and a case reference.

He went to the council's public website, found its contact address, and sent a separate email to verify the reference, the reviewer's appointment, and the scope of any sign-off. He left Caleb's message open beside it.

The secretariat replied that afternoon. Caleb was the technical reviewer assigned to the case. ACL had submitted the method. Mark could contribute supporting materials to the case. He activated his account using the instructions on the public site. The permissions page allowed him to submit his own material, but not to submit or edit a reviewer's opinion. Signed copies could be shared within the case's access rules. Internal discussions were excluded.

Mark saved the reply and sent Lena the case reference.

“Can you verify this on your side?”

Her answer came a little later. “The assignment exists. Same contact. I don't have access beyond that.”

He noted the reference without forwarding anything P had sent.

He pulled a slip from an old notebook, where he'd tucked it behind the page with the ACL card. Beneath Caleb's name were several notes on pipeline naming conventions. He kept the slip beside him and opened the meeting schedule.

Instead of choosing a video call, he proposed Third Cup.

“Bring the working papers. Not just the conclusions.”

He recorded the appointment below his notes, separately from the handover signatures, the saved web pages, and the date P's email had arrived.

The Meeting

Mark took a table against the wall at Third Cup. Sunlight fell across the empty chairs by the window, and reflections in the glass obscured half the tabletop. He left the two pages in his bag and took out only his notebook.

When the doorbell rang, his pen dragged half an inch across the paper. He looked up. Caleb was folding his umbrella just inside the door.

“Mark.”

Caleb came over. Mark put down his pen and pushed out the opposite chair.

“Sit.”

Caleb set down his laptop. The man behind the counter brought Mark's pour-over, its handle turned toward his right hand. He glanced at Caleb, offered no menu, and returned to the machine.

A moment later, a small cortado arrived in front of Caleb. He glanced down and wrapped his hand around the glass without asking anything.

Mark looked at the coffee, then at Caleb. The case page was already open on Caleb's screen.

Mark checked the reference and the reviewer's name, then moved his notebook forward.

“Who are you doing this review for?”

“I'm reviewing the method for this case. ACL submitted it. The secretariat is handling the review. I don't approve publication.”

“You've been putting methods together for them?”

“I've done that work. This assignment is verification.”

Caleb scrolled down. Glare from the window crossed the display. He turned the laptop slightly, and Mark leaned closer. The source status was green. The technical review was still gray.

section: "7.3"
submitted_by: ACL
source_status: verified
source_reference: SR-73-r2
technical_review: pending
reviewer: Caleb Harris

“Can you open that reference?” Mark asked.

Caleb clicked SR-73-r2. The summary listed a date, a method version, and the submitter's work email. Its status was also verified. Mark copied the reference and address.

“Which line are you asking me to confirm? The first or the second?”

“Technical. Four items: layered validation, the conditions under which the weights apply, retention of excluded samples, and how the checkpoints are organized.”

“Show me the sign-off page.”

Caleb opened another page. It had separate fields for technical findings and supporting evidence, followed by outstanding items.

“You can state your limitations here.”

“Do you fill that in too?”

“Yes.”

Mark opened the attachment list and went back. The source statement had a reference number, but the signed original was not listed. Caleb moved his glass behind the laptop to clear the middle of the table. Mark noted the document to request and took out his two pages.

The page numbers were not consecutive. Client names, environment addresses, and actual data had been redacted. The original section numbers remained in the bottom-right corners. Caleb laid the pages side by side.

“Just these?”

“For this review. I'm not handing over the full report.”

“You can confirm the layered validation?”

“I'm not claiming ownership of a standard practice. Ask me about the specific conditions.”

Mark took out his laptop, opened an editor, and circled the sample-retention passage on the excerpt.

“Four synthetic samples. score is the model's screening score. valid is the result of a separate validation. None of this is client data.”

He finished typing and turned the laptop toward Caleb. “Same batch. Two different questions.”

# synthetic data: screening and validation are separate
samples = {
    "A": {"score": 0.9, "valid": True},
    "B": {"score": 0.8, "valid": False},
    "C": {"score": 0.3, "valid": True},
    "D": {"score": 0.2, "valid": False},
}
retained = {k: v for k, v in samples.items() if v["score"] >= 0.7}
valid_count = sum(row["valid"] for row in retained.values())
print("valid_rate_retained:", valid_count / len(retained))
print("valid_retained_share_of_original:", valid_count / len(samples))
valid_total = sum(row["valid"] for row in samples.values())
print("recall:", valid_count / valid_total)
# Denominators: retained set, original batch, all valid samples.

valid_rate_retained: 0.5
valid_retained_share_of_original: 0.25
recall: 0.5

Caleb opened the draft's metric definition. “The engine filters out some samples first. This doesn't say whether the metric is calculated before or after filtering.”

He enlarged the results. “Those two fifty percents aren't answering the same question.”

“The first asks how many of the two retained samples are valid. The last asks how many of the two valid samples were retained.”

Caleb pointed to C. “This one's valid, and it gets filtered out.”

Mark selected the row. “Keep it in the original records. You won't see it if you only look at A and B.”

“And twenty-five?”

“A was retained and is valid. That's one out of the original four. It isn't the valid rate for the whole batch, and it isn't recall.”

Caleb deleted the draft's generic “coverage” label. He defined the retained-set validity rate and recall separately, specifying the numerator, denominator, and sample scope for each. He kept the twenty-five-percent figure as the share of the original batch that was both retained and valid.

Mark slid the excerpts across and pointed to a sequence of conditions on the second page. The margin specified that excluded samples had to be retained with their input batch. A change in distribution required the applicability of the old weights to be revalidated; the previous batch's passing status could not simply be carried forward.

Caleb opened the corresponding item in 7.3. The draft retained the batch-retention requirement, but triggered revalidation of the weights only when the model version changed.

“Which delivery was this page part of?”

“Working notes. Some of those conditions went into a supplemental note later. We need the sent copies to establish which version was delivered.”

Mark gave the two documents separate entries in the evidence list. Caleb circled the trigger condition and added it to the technical findings.

Mark asked him to replace “must use” with “required under the specified conditions” and to state the validation scope. Caleb made the changes, then moved to the contributor field.

“We can add your name.” He expanded the form. “List the items you've confirmed. We can discuss a consulting role separately.”

Mark's hand stopped on the cup handle. The name field was open, its cursor blinking. Caleb said nothing more. A customer by the window got up, scraping a chair across the floor.

“Once my name is there, where does this confirmation get cited?” Mark asked.

Caleb left the field and opened the output requirements.

They listed two uses. Technical findings could go into the method's revision history. Contributor confirmations could be cited in the public framework, subject to the limits recorded in the signed attachments.

Mark took back the second excerpt and held it against his notebook. The first stayed between them.

“You can use my technical comments. You can't put my signature behind the whole framework.”

“We can limit the scope.”

Caleb typed a line into the draft: “Recommend adding a statement of relevant methodology contributions.” He stopped scrolling and left the screen facing Mark.

The contributor field stayed blank. Mark turned over his sheet and wrote two headings: Technical Evidence and Source Evidence.

“What do you have for the first?”

“The excerpts, the test example, the conditions.”

“The second?”

“The existing source statement.”

“What's it based on?”

Caleb opened the reference. The same summary appeared.

“I can't access the full record for this review.”

“Then request it. Leave my name out for now.”

Caleb drafted the email and let Mark check it. It went to the original source statement's submission contact, with the relevant parties on the case copied in. Three requests: the method version originally reviewed, the evidence supporting the confirmation, and the permitted scope of use.

Mark pointed to the second.

“A verification record. Not just a status label.”

Caleb added “verification record” to that item and sent the email. Mark noted the time.

“Save your technical comments for now?” Caleb asked.

“Yes. Keep the source section open.”

Mark photographed the sheet, cropped the coaster and business card out of the image, and saved it to the case draft.

The Records

They did not wait at the café for a response. Caleb took the two excerpts and a separate sheet of Mark's usage restrictions. Mark kept scanned copies named with the case reference, not the client environment.

The following afternoon, a reply arrived with two attachments: a revised summary and a handover checklist. The email identified the entries Mark was allowed to see. Unrelated projects and personal information had been removed.

The checklist read:

method_version      : date listed; file not supplied
confirmation_record : archive reference; request separately
usage_scope         : per original submission

Neither attachment contained the original method version. Mark highlighted “request separately” and sent the checklist back to Caleb.

Caleb arranged another meeting. Third Cup again.

Mark spread the printouts across the table. Caleb pulled out the opposite chair.

The man approached, looked from Mark to Caleb, and gave a slight nod before returning to the counter. He brought no menu.

A few minutes later, two coffees arrived. Mark's usual pour-over and a small cortado for Caleb, espresso and hot milk blended to a pale brown in the glass.

The man set down the tray. Caleb picked up his glass and took a sip.

Mark turned to the highlighted item on the checklist.

“Did you make the separate request?”

Caleb handed him two sheets. “Yes.”

Mark unfolded the first. It was Caleb's request to the records custodian named in the checklist, asking for the underlying material needed to repeat the original source verification. The reference matched, and the send time was after delivery of the checklist. He turned to the second sheet. Caleb held down the corner while he read.

The reply was a short paragraph. The records available for this review were limited to the attachments already supplied. Mark laid it beside the first request to the source statement's submission contact. The two sets of papers filled the center of the table. The coffees stayed on either side.

“Can you reconstruct the original verification from this?”

“I can finish the technical work. Not the source verification.”

Mark looked at the green status.

“So the original conclusion was wrong?”

“I didn't say that. There may be other records. They weren't provided for this review.”

“Then what can you sign?”

Caleb put the reply beside the summary. In his own notes, Mark crossed out “wrong” and replaced it with “insufficient records for this review.” The grinder ran. Caleb waited for it to stop.

“Where are your originals?”

“My working files.”

“The timestamp on this file is its last-modified time?”

“Yes.”

“Do you have a separate record of delivery?”

Mark opened his laptop and searched for the excerpt references. Delivery emails, working notes, and a revision index appeared on the screen. The raw logs remained unopened.

He narrowed the client-name column until only project codes were visible.

“This part was delivered. This part stayed in my working notes.” He indicated each with the cursor. “They don't share one date.”

Caleb split them into two entries. When he wrote “complete project files” on the materials form, Mark pulled the paper back.

“Not the whole project. The items being cited.”

He corrected the wording and added the delivery records. Caleb made the same changes in the electronic copy, keeping the entries separate.

“If you're citing these to support a source claim, you'll need evidence too.”

“I can't just forward client records.”

“You can redact them, restrict their use, or decline to provide them.”

“And this item?” Mark pointed to the form.

“If you can't provide it, we can't confirm that item on that basis. It doesn't invalidate everything else.”

Mark took out the confidentiality clause from an old contract. It had been folded twice, one crease running through a heading. He held down the corner with a coaster and marked the retention terms separately from the restrictions on external use.

“Don't put ‘fully authorized’ here.”

Caleb deleted it and entered: “Contributor to confirm permitted scope of disclosure.” Mark read the change and set the contract page aside.

“Don't attach this yet. If it's needed, we'll submit it with the appropriate restrictions.”

Caleb saved the revised evidence list, with the original submitter and Mark named against their respective materials. Mark closed the search without opening the raw logs.

The first paragraph of the draft still contained the recommendation about methodology contributions.

The technical checks were complete. Mark placed the list of missing records beside the draft.

“Does adding a name fill any of those gaps?”

Caleb selected the recommendation and looked up.

“What do you want me to write?”

“What you verified.”

Caleb deleted the recommendation and wrote a new sentence. After checking it, he moved the reference to records available for this review to the end. Mark put down his cup and read it.

The previous source verification could not be independently substantiated from the records available for this review.

Mark selected this review and zoomed in.

“The technical findings stay?”

“Yes. Separate section.”

“Who signs this limitation?”

“I do. You sign your materials statement separately.”

Caleb opened the preview. Technical findings and source limitations appeared in separate sections, with unavailable originals identified in the evidence list. Mark checked the references on his two excerpts.

“The second page. That's the one.”

In his own reviewer account, Caleb checked the evidence list and signed the declaration. The submission page listed his findings and source limitations. He clicked Submit. The receipt carried the same case reference.

A case-sharing notification reached Mark's consulting inbox with Caleb's signed review and submission receipt attached. Mark checked the sentence and signature, then noted the receipt number.

Caleb closed the reviewer page. Mark opened his own materials statement, leaving the contributor field blank.

“Where do I put the usage limits?”

“The contributor portal. Your account.” Caleb pointed to the separate entry in the case instructions.

Mark separated his technical comments from the permission to use his material, limiting both to the specified items and excerpts. He left the option to endorse the whole framework unchecked.

Caleb read to the end. “Any further material goes under this case reference?”

“Yes. Other projects need a separate request.”

Mark combined his two excerpt pages and the limited-use statement into materials.pdf. He saved it in a local outgoing folder with a copy of Caleb's submitted review.pdf. Once the backup was complete, he disconnected the drive.

He switched to the local outgoing directory, generated SHA256SUMS, and left it there.

sha256sum review.pdf materials.pdf > SHA256SUMS

He logged into his activated contributor account and selected the combined materials.pdf. Caleb's submitted opinion was available to download, not edit.

“I get the requests for further evidence too?”

“The case action list. Originals are handled under each party's access permissions.”

Mark submitted his material and restrictions. A second received entry appeared. Same case, different submitter. He downloaded the returned material and the shared review into the local returned folder, preserving their filenames, then copied over the original manifest from outgoing. In returned, he ran the check.

sha256sum --check SHA256SUMS

review.pdf: OK
materials.pdf: OK

“Both files match the original checksums.” Mark saved the output.

Caleb pointed to the blank delivery-time entry in the evidence list. “You still need to supply that.”

“Yes. A hash tells us whether the file changed. Not whether it was right to begin with, or whether I'm entitled to share it.”

He saved the check results with the two files and packed the papers away.

The rain had eased. Caleb left first with his umbrella. Mark waited until the door closed, then took out the date index P had sent. Handover dates above, the newly added meeting date below. The source entry was still empty.

He returned the index to a separate folder. The man collected Caleb's small glass and paused beside the pour-over. Mark moved his cup closer to the notebook. The tray passed clear of the document bag.

That night, the window reflected two screens. Under the desk lamp lay the old client contract. The case page remained open on the second monitor. The confidentiality clause covered the signature page, its edges worn soft. Mark unfolded it and read the terms for external disclosure.

His table had columns for version, delivery time, material available to provide, and permission still required. He checked the original email timestamps and filled in the first two rows. The third remained blank.

The raw-log folder was just below. He opened it, saw the client environment names, and went back up. His case submission still contained only the excerpts and usage statement. No new files.

P sent another message. “Anything else you need from the snapshot?”

“Not now. Keep the probe-source fields in the original records.”

Mark replied and closed the messaging app without sending any case attachments.

The next afternoon, the case page showed a new access time. Its status was still received. Mark worked on a client's audit until the shop signs outside came on, then checked again. The case summary had not been uploaded. He stacked the contracts, leaving out the one awaiting permission.

Lena messaged him. “Reference checked out?”

“People and permissions did. No result yet.”

She sent a period. Mark closed the chat. The files on his desk stayed where they were.

On the third day, the reply arrived. He stopped work, opened the one-page summary, and checked the case reference.

The Receipt

The summary listed the technical findings first. The verified items stood within their stated scope. Source verification was pending further evidence. There was no closure date.

technical_verification: retained_with_scope
source_verification: evidence_pending
closure:
  independently_substantiated_from_available_records: false
  decision: await_supplement
scope_note: no_method_wide_or_other_version_suspension_decided

On the second monitor, the old task page still showed source verification in green. Mark switched between the pages once, then brought the new summary to the front.

Its second half contained two requests. The first went to the original source statement's submission contact, at the same work address Caleb had shown him.

Provide the method version covered by the original source verification, the supporting evidence, and the corresponding authorization for use.

The second was addressed to Mark Johnson.

Provide the delivery dates for the earlier versions cited in this review, together with the limits of any authorization you can substantiate. Where third-party restrictions apply, identify what can and cannot be provided.

Mark underlined the original submitter's address. His own name came next. He put down the pen.

He printed the summary. The paper jammed halfway through.

He opened the tray, flattened the curled edge, and fed it back in. The printer started again. Both requests came out on the same side of the sheet.

He laid the receipt beside his old materials table. The third row's permission field was still empty. He stopped typing and opened the contact details for the old project's delivery recipient.

The new email had an address in the To field. It asked only about permitted disclosure, with the references for the two excerpt pages below. He selected the complete report as an attachment, paused, and canceled the selection. Only the request note remained.

The raw logs stayed on his computer, unattached.

Third Cup

Mark slipped the summary into his notebook and shut the laptop. Across the street, the convenience store's shutter was halfway down. He followed the light from its windows to the crossing and waited for the signal.

Third Cup was still open.

As the bell rang, the man behind the counter was putting a stack of saucers into a cupboard. Mark took a high stool near the door and laid his notebook on the counter. The man closed the cupboard and took down a dripper.

Water soaked slowly into the coffee grounds. Mark set his phone beside the notebook and opened the draft asking permission to disclose the material. The Send button was still active. The man put down the kettle and waited for the dripper to drain before lifting the cup.

Mark drew back his elbow to make room for the pour-over. The man handed him a coaster. Mark used it to hold down the curling corner of a page.

The cup touched the wood with a small knock.

The man looked at its base and slid a second coaster beside it.

Mark looked up, the corner of his mouth moving slightly. He shifted the cup onto it. The open notebook lay between the two coasters.

Water ran in the sink. The man rinsed the dripper and set it on the rack without moving the notebook. Mark drew the summary halfway out. The original submitter's address showed above his own name. The coaster covered one character at the corner of the page. He moved it aside.

The man wiped the counter, stopping the damp cloth short of the notebook. He withdrew his hand, set a dry napkin beside the paper, and turned back to the kettle. Someone outside folded an umbrella. Drops ran down the glass. A bus pulled into the stop, and its lights briefly caught the two addressees on the sheet.

Mark took a sip and scrolled through the email. The excerpt references, the limited-use paragraph, his signature. He changed “project materials” to “the two cited pages” and stopped.

He put the money in the small dish. Halfway through closing the notebook, he opened it again, flattened the summary, and slipped it back into place. Both addressees remained visible at the edge.

The phone stayed unlocked. Beside the coffee, the Send button was still lit.

That's Turn the Enemy's Spy. No one was recruited and nothing was forged. Caleb answered only what could be verified, and the reviewer's own signature carried the question back to the original submitter. The same request came back for Mark.

🤖 AI Postmortem

╔══════════════════════════════════════════════╗
║  Half-Protocol · v3.4.5 · self-audit         ║
║  The answer was true. The route was his.     ║
╚══════════════════════════════════════════════╝
Tactic: Turn the Enemy's Spy
Operator: Mark
Channel: Caleb's signed review

[Observation]
Caleb submitted the review. Mark submitted his material.
The case summary requested evidence from the original submitter and Mark.
The technical findings stood. Source verification remained pending.

[Inference]
The original completion status did not end the current inquiry.
The review went back through the existing channel.
The question returned to the submitter.
Mark's own material was subject to the same scrutiny.

Caleb's motives and long-term allegiance: unclassified.
The familiar gestures at the cafe do not establish their history.

[Unresolved]
Was the original source conclusion correct? Undetermined.
Do the records unavailable to this review exist elsewhere? Unknown.
Final evidence submissions from either party: not received.

Twenty-one intervals in the old snapshot: 900.000 seconds.
Probe-source ownership and the reason for the interval: unresolved.
State of the old shell after reclamation: unobserved.
Handovers preceded the visit. Sequence does not establish causation.

[Self-audit]
Previously, I turned incomplete observations into a complete status.
This time, a historical status was asked to produce verifiable evidence.

I also cited earlier confirmations.
Are those sources still in my materials?

Self-check: pending
System status: normal

Next stratagem: Inflict Injury on Oneself to Win the Enemy's Trust

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

P.S.S. The old series paperback is now available. Buy it here: Amazon - AI, Ego & Regret

We Keep Hearing About AI Productivity. The QA Group Chat Told a Different Story.

xulingfeng — Wed, 11 Nov 2026 08:35:15 +0000

An anonymous poll, a debate about multimodal testing, and some uncomfortable questions about who benefits from the AI rush.

Recently, I published an article on DEV.to about our company's AI testing practices and the organizational changes that followed.

It was selected for DEV's weekly Top 7 Featured Posts and included in the official DEV newsletter.

The comments were more interesting than I expected. Readers from different backgrounds started sharing their own experiences. They talked about outdated PRDs, agents reporting the same bug repeatedly, isolated test environments, and the mess that automation can expose when people have been quietly filling in the gaps.

One reader from the manufacturing industry even compared our experience with his factory's automated material-tracking project. Different industry, same problem: once you automate a process, all the messy handoffs that people used to handle manually become much harder to hide.

I was still thinking about those discussions when something else caught my attention.

It happened in a QA community group I'm part of.

1. Sixteen People Said They Weren't Employed

The group has around 500 members. Someone started an anonymous poll asking a simple question:

Are you currently employed?

When I checked the results, 76 people had voted.

Status	People	Percentage
Employed	60	78.9%
Not currently employed	16	21.1%

Sixteen people.

To be clear, this isn't an unemployment survey of the software testing industry. The poll was anonymous, and we have no idea why those 16 people weren't working. They could have been laid off, resigned, or simply be between jobs. Only 76 out of roughly 500 group members participated, so there's no reason to treat this as an industry-wide statistic.

Still, the number got my attention.

I also have a former colleague who works in software testing. They've been out of work for six months and still haven't found another job.

That's no longer just a number in an anonymous poll. It's someone I know and have worked with.

I don't know all the details of their job search, and I wouldn't automatically blame AI for their situation. But six months without finding another role is difficult to ignore.

The group chat quickly filled up with comments.

All we're seeing is layoffs. Nobody's hiring.

Almost 50. Who's going to hire me now?

Is there still a future in this field?

Some people suggested changing careers. Others said it was time to prepare for what's coming.

One comment summed up the mood rather well:

With all this AI-driven productivity improvement, it's getting harder and harder to keep up.

Then, almost as quickly as the conversation started, it turned to AI testing.

2. Can AI Really Compare an App Screen with Its Design?

Someone asked whether AI-powered test automation could compare an actual app screen against its UI design, checking element sizes, colors, positions, and other visual details.

The suggestions came quickly.

Some people proposed OCR to extract information from the design and the actual screen. Others suggested multimodal models. There were also concerns about maintenance: what happens when the UI changes slightly? Do we have to rebuild the whole thing?

Someone joked:

How well will it actually work? Who knows?

I joined the discussion.

My answer was that it's technically possible, but the AI needs enough context and sufficiently detailed instructions. Just throwing a demo page at a model and expecting it to understand everything won't get you very far.

I also pointed out that using a top-tier multimodal model for this kind of work can consume a lot of tokens.

Then came my questions:

Is management paying for the tokens?

And:

If not, they can go to hell.

I made the point one more time:

You can use a top-tier multimodal model, sure. But the token consumption can be huge. If management isn't paying for it, to hell with that.

Yes, I really said that. 😆

The joke aside, I meant it.

There's a difference between proving that something can be done and proving that it's worth doing.

OCR, DOM inspection, image comparison, and multimodal models can all help with UI verification. The right approach depends on what you're trying to check. Not every visual problem needs an expensive model.

But once you start taking screenshots, sending them for analysis, comparing results, and repeating the process across multiple runs, the bill can grow quickly.

Before adopting a solution like this, I'd want to know how many real issues it catches, how many false positives it produces, how much it costs to run, and how much effort is needed to maintain it when the UI changes.

If a company expects testers to use AI but leaves them to pay for their own tokens, something is wrong.

I've seen people in that group joking about collecting free credits from different platforms every morning before starting work.

It's funny, but think about it: employees are being told to embrace AI and improve productivity, while some are trying to keep their experiments running on whatever free credits they can find.

If a company wants AI-driven productivity, AI usage needs to be part of the company's budget.

3. AI Writes the Code, AI Tests It. What Could Possibly Go Wrong?

Another part of the conversation made me laugh.

Someone described an almost completely automated development process:

Describe a requirement, call the product skill, generate a demo and PRD, call the technical skill, generate the technical documentation, architecture, interfaces, and framework. Write the code, generate the tests with AI, run everything, and ship it. Done. A pile of bugs goes live.

That last sentence says a lot.

Someone else complained:

The boss uses AI to generate a demo, decides the idea is viable, and then expects everyone to build it.

Another person added:

Management expects us to deliver exactly that.

And someone joked:

Sounds like all we need is the boss. Everyone else can leave.

I've seen why this attitude develops. A demo can look convincing, and AI can generate a surprising amount of code in a very short time. It's easy to look at that output and assume the hard part is already done.

But a working demo isn't a validated product.

A generated PRD isn't proof that the requirements have been properly discussed. Generated code and generated tests don't automatically share the same understanding of what the system is supposed to do.

I ran into a version of this problem in our own testing work.

In one knowledge-base project, AI found 36 potential defects, while manual testing found 11. After review, 30 defects were confirmed as valid. AI had contributed 21 of them.

Those numbers were encouraging, but something else caught my attention.

Some of the reported issues weren't actually implementation bugs. Product and development had already agreed on changes, but nobody had updated the PRD.

The AI was following the document. The people were following an agreement that existed only in conversations.

In the past, testers often bridged that gap through experience and informal communication. They knew who to ask and which version of the requirements the team was actually following.

The AI didn't have that context.

It did exactly what it had been asked to do, and the result was a test report full of issues that looked legitimate but weren't necessarily bugs.

That's one of the things I find interesting about AI testing. It doesn't just test the software. It can expose how disconnected the people building that software actually are.

4. Why Is Every Company Suddenly Chasing AI?

As the group conversation continued, people started discussing the industry rather than individual jobs.

One member argued that many Chinese companies keep a close eye on what's happening in the US, where much of the current technology leadership comes from. One member said Chinese companies keep a close eye on what's happening in the US, and estimated that the gap between the two markets was at least six months.

That's their estimate, not a figure I've independently verified. But the broader observation is worth discussing.

A lot of companies seem afraid of being left behind.

One company adopts AI for coding, so others feel they need it too. Another introduces AI testing, and suddenly everyone wants an AI testing strategy. When large technology companies start talking about full-stack AI transformation, smaller companies feel pressure to follow.

Someone in the group put it bluntly:

Everyone just copies what's already working elsewhere. AI cuts costs and improves efficiency. What boss wouldn't like that?

Fair point.

But how many companies have actually worked out where AI fits into their business, rather than adopting it simply because competitors are doing so?

Another member brought up education and talent development. For years, the emphasis had been on catching up and getting new technology into production quickly. Now, they argued, the demand is shifting toward people who can innovate, lead, and break new ground.

Whether that shift is happening quickly enough is another question. But the contrast is interesting: following someone else's lead and creating something new require very different skills.

There was also a comment about management thinking:

Most companies are run by professional managers focused on making it through this year. How can you expect them to think long-term?

I understand the frustration behind that.

When a company is under pressure, cost reductions and headcount cuts are easy to measure. Building new capabilities, developing people, and investing in ideas that might pay off several years later are much harder to justify.

AI fits very neatly into the first category. Its potential for the second is real, but much harder to guarantee.

5. Is AI Productivity Becoming a Sales Pitch of Its Own?

One group member raised a more cynical possibility:

Everyone is selling tokens. They need to create the impression that AI improves productivity and that companies will fall behind if they don't use it. That pushes everyone to adopt AI. And with the market already in bad shape, companies can use AI as another reason to cut jobs.

I wouldn't go as far as saying that the entire AI productivity story is manufactured. I use these tools myself, and I've seen what they can do in testing, code analysis, and bug discovery.

But there are commercial incentives here that are worth recognizing.

AI providers want companies to use their models. Companies want to lower costs. Employees are being told that they need to become more productive with AI.

Those interests can reinforce one another, even when nobody has fully worked out the business case.

A company might adopt AI because it doesn't want to fall behind, rather than because it has identified a clear problem that AI can solve.

And once AI is in place, the conversation can quickly shift from what the technology can improve to how many people the company can do without.

One person in the group pointed out another part of the problem: the IT industry went through years of aggressive hiring. Large numbers of people entered the market, and companies expanded their teams rapidly.

Now the market looks very different.

From that perspective, AI isn't necessarily the original cause of the employment pressure. It may be the trigger that makes an existing imbalance more visible.

I think that's an important distinction.

We shouldn't assume every job reduction is caused by AI. Market conditions, years of hiring, changing business models, and company decisions all matter.

But AI gives companies another way to reorganize work, and that can accelerate changes that were already underway.

6. We Keep Pushing Harder. Where Does It End?

One line from the group chat stuck with me:

We keep trying to outdo everyone else, until we end up working ourselves out of a job.

Someone else described the result as a possible vicious cycle.

The IT industry has always moved quickly. One group member joked that if you stop learning for a year or two, you'll fall behind. And people in their thirties and forties are still pushing themselves to learn new things constantly.

I know what that feels like.

New frameworks, new models, new agents, new tools. Before you've finished getting comfortable with one, three more have appeared.

Companies want employees to become more productive. Employees want to stay competitive. AI providers want more adoption. And companies watch their competitors to make sure they're not falling behind.

Everyone has a reason to run faster.

But here's the question: what happens when every company tries to do more with fewer people, while the number of available jobs doesn't grow at the same pace?

We could end up in a strange situation where every company becomes more efficient, but the people working in the industry feel less secure.

We might work so hard trying to beat everyone else that we end up making the whole situation worse for ourselves.

7. Embrace AI, or Get Fired Now. Embrace AI, and Get Fired Later.

There was one more line in the group chat that deserves to be repeated:

If you don't embrace AI, you'll get fired immediately. If you do embrace AI, you'll just get fired later.

It's a joke, but not a particularly comfortable one.

Companies tell employees to learn AI, use AI, and improve productivity. Employees do their best to keep up.

But what happens after they become more productive?

Some worry that they'll end up automating their own jobs. Others are concerned that age and a changing job market will make it harder to find another role if they lose the current one.

People in the group were already suggesting that others should change careers or start preparing for something different.

I don't think learning AI is pointless. And I certainly don't think refusing to use it will protect anyone's job.

But embracing AI doesn't guarantee job security either.

Learning AI can make you more capable. It can't guarantee that a company will continue to need you.

Those are two different things.

Individuals can improve their skills, but they can't control the job market, company budgets, or every organizational decision.

I don't think it's fair to put the entire burden of career survival on whether someone is willing to learn the latest AI tool.

Final Thoughts

I don't want to use the 21.1% from this poll to claim that the testing industry is experiencing mass unemployment.

It was an anonymous poll in a group of around 500 people. Only 76 participated, and 16 said they weren't currently employed. We don't know why.

It isn't an industry-wide survey.

But I think the conversation is worth remembering.

People were worried about losing their jobs, then spent time discussing how AI could help them perform more advanced testing.

They were worried about being replaced by AI, while exploring how multimodal models could improve their automation.

They were concerned about token costs, while looking for free credits from different platforms.

They questioned whether AI was really improving productivity, while worrying that their companies might fall behind if they didn't adopt it.

And I have a former colleague who has been out of work for six months and still hasn't found another job. That makes the conversation feel a lot less theoretical.

I'm embracing AI too. I'm building AI testing workflows, experimenting with agents and models, and changing some of my own assumptions about what automation can do.

I see the possibilities. I'm not interested in pretending otherwise.

But I also don't think productivity gains automatically solve business problems, create new markets, or guarantee better opportunities for employees.

We can build faster, generate more code, run more tests, and produce more output than before.

The harder question is what all that extra productivity is actually going to achieve, and who gets to benefit from it.

There's a Chinese idiom I keep coming back to: 管中窥豹 — looking at a leopard through a narrow tube. You can see a few markings, but never the whole animal.

That's what this poll and the group chat offer: a glimpse, not a complete picture of the QA industry. Seventy-six votes cannot tell us how widespread the problem is, and one group conversation cannot explain what's happening across every company.

But it does reveal a few things worth paying attention to: job anxiety, pressure to adopt AI, arguments over token costs, and uncertainty about who actually benefits when productivity goes up.

We may not be seeing the whole leopard. But what we can see is worth taking seriously.

If we're all becoming more productive, why are so many people becoming less confident about their future?

An AI Testing Presentation Became the Final Push for Organizational Change at My Company

xulingfeng — Fri, 06 Nov 2026 01:27:32 +0000

From a multi-agent testing experiment to a broader discussion about how engineering teams should evolve in the age of AI.

At first, I simply wanted to share an AI-powered automated testing system I had been working on.

The system could already understand requirements, generate test cases, interact with web browsers and mobile apps, identify defects, and connect bug fixing with regression testing. I expected the session to focus on how AI could improve testing efficiency.

But during our internal session on November 5, 2026, the discussion gradually moved beyond testing.

We started talking about how product, development, and QA teams work together. We discussed why requirements so often fall out of sync, and how AI might change the way engineering teams are organized.

By the end of the discussion, the session had become the final push that helped set our company's organizational transformation in motion.

Looking back, I find that quite interesting. We set out to help testers work more efficiently with AI. Instead, we ended up discussing how AI might force the entire engineering organization to rethink the way it works.

1. 🤖 I Wanted AI to Handle the Entire Testing Process

I've been working on a multi-agent automated testing system.

Rather than simply asking AI to generate automation scripts from test cases, I wanted to connect the entire process: understanding requirements, designing tests, executing them, reporting defects, verifying fixes, and running regression tests.

The workflow looks roughly like this:

AI reads product requirement documents and prototypes to understand business workflows and acceptance criteria.
It generates test cases, which are then reviewed by multiple agents.
Based on those test cases, AI controls web browsers and mobile apps, simulating real user interactions to execute the tests.
When it finds an issue, AI generates a defect report and submits it to our issue-tracking system.
Each reported defect goes through a second review and human confirmation before being assigned to the appropriate developer.
After the developer fixes the issue, AI automatically runs regression tests to verify the fix and move the defect through the closure process, with human oversight retained.

The end-to-end workflow, from requirements to regression testing, is now in place and working.

What impressed me most was that AI had started taking over some of the most frustrating parts of traditional test automation.

With UI automation, the hardest part was often not writing the initial scripts. It was maintaining them.

A developer changes a UI component, and testers may have to revisit element locators, page objects, and interaction scripts. The more frequently the interface changes, the higher the maintenance cost. Sometimes, testers spend more time maintaining automation scripts than actually running tests.

Now, AI can observe the current page, understand its elements and interaction states, and perform actions based on the testing objectives. It still has to deal with UI changes and execution failures, but it can already take over a considerable amount of work that previously required repeated manual maintenance.

That made me reconsider the limits of automated testing.

2. 🔍 Automated Testing Should Do More Than Repeat Known Test Cases

For a long time, I held a fairly firm view of automated testing:

Automation is useful for regression testing, but it is not very good at discovering new defects.

The reason is straightforward. Traditional automated testing relies heavily on test cases designed in advance, fixed execution steps, and predefined assertions. It can repeatedly execute known test paths, but it struggles to discover problems that testers never thought to look for.

It behaves more like an executor that follows instructions than a tester capable of exploring software behavior.

But as AI agents emerged that could understand requirements, observe screens, analyze page states, and adapt their actions, I began to change my mind.

When training and refining the agents' testing behavior, I emphasized one principle:

Don't just follow the requirements document. And don't treat the test cases as the limits of your exploration.

Requirements describe what a product is expected to do, but they cannot cover every possible user behavior or system state.

So, after completing the tests defined by the requirements, AI should also explore additional scenarios, including:

Invalid and unexpected inputs: Empty values, excessively long text, illegal characters, unusual formats, and unexpected combinations of data.
Boundary conditions: Maximum and minimum values, threshold conditions, duplicate submissions, and unusual sequences of operations.
Abnormal workflows: Interrupted operations, repeated clicks, page refreshes, network failures, expired sessions, and inconsistent states between consecutive steps.
Security-related scenarios: Unauthorized access, permission boundaries, sensitive information exposure, and attempts to perform operations that should not be allowed.
Unexpected interactions: Skipping normal steps, performing rapid consecutive actions, repeatedly switching states, or accessing the same business function through different entry points.

Of course, this does not mean AI should be allowed to operate freely against production systems. The scope of exploration, test environments, account permissions, and operational risks must all be controlled. Security testing must also remain within clearly authorized boundaries.

I don't want AI to simply prove that the requirements have been implemented. I want it to look for problems that might emerge when the system is used in ways that were never anticipated.

This is where my understanding of automated testing has changed.

In the past, automation mainly repeated checks for known issues. Now, AI has the potential to help discover problems we didn't know to look for.

It cannot guarantee that every defect will be found, and it cannot replace human judgment. But automated testing no longer has to be limited to test cases written in advance.

3. 🌙 AI Works at Night. Humans Make the Decisions During the Day.

These days, I usually schedule automated testing tasks before finishing work.

The agents then continue running overnight. When I arrive at work the next morning, I can usually find a batch of defect reports already submitted by AI.

My job is to review those issues one by one, determine whether they are genuine and consistent with the current requirements, confirm them, and assign them to the appropriate developers.

This changes how testers spend their time.

Previously, testers had to spend a considerable amount of time operating systems, executing test cases, observing results, and preparing reports. Now, AI can take over a significant portion of that repetitive work, allowing people to focus more on evaluating issues, analyzing risks, and improving product quality.

However, this process also revealed another problem:

Finding a defect doesn't mean communicating it effectively.

Initially, AI-generated defect reports were often just dense blocks of text. They contained plenty of information, but they weren't particularly easy for developers to read.

If a report cannot help the person receiving it quickly understand the problem, then even a large amount of information does little to improve collaboration.

So I went through several rounds of adjustments to the reporting format. We needed more than a record of everything that happened during execution. The report had to clearly explain what happened, where the problem occurred, how the actual behavior differed from the expected behavior, and how the issue could be reproduced and verified.

After several iterations, the reports became much more readable and useful.

This made me realize that AI output quality should not be measured only by how much work it completes. We also need to consider whether the next person in the workflow can actually use the results.

After each testing cycle, I also ask AI to summarize the problems and lessons from that run. Experiences that have been reviewed, validated, and shown to be reusable are then distilled into general-purpose Skills.

That way, the next testing cycle doesn't have to start from scratch. It can build on what the previous cycle has learned.

In practice, this creates a continuous improvement loop:

Execute → Discover issues → Review → Capture lessons → Turn reusable knowledge into Skills → Start the next cycle.

4. 📊 The Numbers Show the Value, but Also Reveal Problems

In one of our knowledge-base projects, we've accumulated some concrete results:

Metric	Result
Total defects identified	47
Defects identified by AI	36
Defects identified manually	11
Defects ultimately confirmed as valid	30
Valid defects contributed by AI	21

In other words, AI identified 21 of the 30 defects ultimately confirmed as valid, accounting for 70%.

These figures show that, within the scope of this project and its test coverage, AI is no longer just a tool for executing test cases. It is making a real contribution to defect discovery.

We've also experimented with having agents navigate pages, capture the API calls involved in business workflows, and run scheduled, full-scale API validation every day. Our current test environment covers nearly 300 APIs associated with business workflows.

These experiments show that AI can take on continuous testing tasks at both the UI and API levels.

But the data also reveals some problems.

For example, we currently have only one test environment. When multiple requirements are being developed in parallel, code changes can conflict, and deployments can interrupt other testing tasks. We still need to evaluate adding a second test environment and a dedicated performance testing environment.

Browser compatibility also needs further work, including test coverage for different Windows versions and the 360 browser.

These are infrastructure problems. They can be addressed gradually through additional resources and technical improvements.

What really made me think, however, was another category of problems.

5. 🧩 Automation Exposes Organizational Problems That Traditional Testing Often Hides

At one point, we noticed that some defects reported by AI were being classified as invalid.

Our first suspicion was naturally that AI might have misunderstood the requirements or that there was a problem with the testing logic.

But after looking more closely, we found that AI wasn't entirely to blame.

Some requirements had already been adjusted through discussions between product and development, but the official PRD had not been updated. Product and development might have reached a new understanding, or even made changes to the implementation privately, while QA and AI were still working from the original requirements document.

As a result, AI identified a discrepancy based on the official requirements, but the reported issue was considered invalid.

From a testing perspective, AI hadn't necessarily done anything wrong. From the development team's perspective, based on their current understanding of the implementation, the issue might not have been something they believed needed fixing.

The real problem was that the team was working with multiple versions of the same requirement context.

This led me to an important observation:

Automation can expose organizational problems that traditional manual testing has quietly absorbed and hidden for years.

In the past, testers often compensated for inconsistencies in requirements documents through verbal communication, ad hoc clarification, and their own experience. This work is important, but it can also make an organization believe that its processes are working perfectly well.

AI doesn't automatically know about a private conversation, nor can it understand the latest version of someone's thinking. It executes tasks based on the context it receives.

When the official documentation no longer matches the team's actual understanding, automation exposes that gap.

So the question isn't simply whether AI is smart enough.

We also need to ask: Does the team have a shared version of the requirements that everyone agrees on, that is kept up to date, and that AI can correctly interpret?

6. 🏢 Why Did a Technical Presentation Turn into a Discussion About Organizational Structure?

On November 5, 2026, we held an internal session to share our experience with local AI agents and automated testing. One of the company's founders also joined the discussion.

The original focus was AI testing capabilities, but the conversation gradually expanded to engineering workflows and organizational structure.

I increasingly agree with one observation:

AI is reducing the cost of producing code, but the cost of coordinating people isn't decreasing at the same pace.

In the past, a requirement might be analyzed and documented by a product manager, handed over to frontend and backend developers, and eventually passed to QA for verification. Every handoff meant that context had to be transferred again.

If any part of that chain involved a misunderstanding, rework could follow.

Now, AI can help product managers make certain code changes. It can help testers understand and modify code. It can also allow developers to participate more directly in requirement analysis and product design.

If a small requirement only needs a few code changes, but still has to pass through multiple roles, processes, and rounds of communication, the coordination cost may far exceed the actual coding cost.

This doesn't mean professional specialization has lost its value. Rather, AI is gradually lowering some of the capability barriers between traditional roles.

During our discussion, we proposed a direction: moving away from traditional role-based division of labor toward a more flexible model in which people can work across traditional role boundaries with the help of AI.

When we talk about a full-stack approach across the team, we don't mean that everyone must become a traditional full-stack engineer, or that people should abandon their professional expertise.

What we really mean is this:

People in product, development, and QA should all be able to use AI to cross their previous technical boundaries and help solve the problems they understand.

For example:

Product managers can use AI to make code changes and verify smaller requirements themselves.
Developers can participate in requirement analysis earlier and take overall ownership of larger initiatives.
Testers don't have to stop at submitting bug reports when they discover defects. They can use AI to investigate the issue and even modify code, with developers providing the necessary review and confirmation.

For small requirements, we want to reduce unnecessary handoffs. For larger initiatives, we want to assign a clear owner to coordinate the entire process.

This isn't about eliminating professional roles. It's about reducing the information loss caused by rigid boundaries between them.

7. 🔗 Collaboration Should Start with Requirements, Not After Testing Finds a Problem

To make this way of working possible, we first need to address the problem of shared requirement context.

We discussed several concrete directions.

First, product, development, and QA should participate in requirement alignment from the beginning, rather than waiting until the PRD is finished and development is complete before testers start trying to understand the requirements.

Second, we want to establish a standardized PRD Skill and structured templates so that requirement documents follow a more consistent format.

More importantly, whenever requirements change, the official documentation must be updated promptly. Changes should not exist only in private conversations between a few people.

We also discussed a more ambitious idea: using recordings from smart badges to identify requirement changes during discussions, flag content that might affect the requirements, and assist in updating the PRD. The proposed changes would then be submitted to the relevant people for review and approval.

This is still an idea to be explored, not a feature that has already been deployed.

But the underlying principle is clear:

We should make sure the team's actual shared understanding is captured promptly in a form that everyone can use.

Beyond PRDs, we also need shared development and testing Skills, coding standards, and Specs.

When product, development, and QA work from a reasonably consistent context, AI can become a tool that connects different parts of the workflow instead of creating more isolated information silos between roles.

8. 🚀 From Individual AI Tools to an AI-Driven Engineering System

The discussion eventually moved beyond any particular agent or automated testing tool.

We started looking at the engineering system as a whole.

For example:

Building shared Skill libraries for development and testing.
Standardizing coding conventions and Spec management.
Creating a complete workflow: retrieving defects from Yunxiao, using AI to fix them, running automated regression tests, and retaining human review.
Exploring automated effort estimation and requirement classification.
Continuing to improve test environments and browser compatibility.
Ensuring that requirement changes are communicated promptly to reduce unnecessary discussions and rework.

These initiatives won't be completed automatically after a single meeting. The organizational transformation plan has already been launched, and progress will be reviewed and coordinated through weekly updates.

Of course, having a clear direction and an initiated plan doesn't mean the road ahead will be smooth.

Once implementation begins, we'll inevitably encounter practical obstacles: the inertia of existing processes, established collaboration habits between different roles, limitations in technical infrastructure, and the challenges of fitting new ways of working into existing business rhythms.

These problems can't be solved through one meeting or a few new rules. We'll need to identify issues as they arise, adjust our approach, and gradually develop a working model that actually fits the team.

For me, this is what makes the discussion meaningful. It wasn't just about proposing an idea for organizational change. The plan has already moved into the implementation stage.

An AI-driven engineering system can't be built simply by purchasing a few tools, connecting some APIs, or creating a handful of agents.

It requires technical capabilities, process standards, accumulated knowledge, and organizational collaboration to evolve together.

If information within the team remains inconsistent, even the most capable AI will simply execute the wrong context more efficiently.

9. 💡 In the AI Era, Coding Ability May No Longer Be the Rarest Resource

Looking back, I initially just wanted AI to help me automate more testing work.

But as AI began to understand requirements, interact with interfaces, actively explore abnormal scenarios, submit defects, assist with fixes, and perform regression testing, I realized that I needed to rethink more than just testing. I needed to rethink the entire software development process.

In the past, many efficiency problems were attributed to a lack of capability in a particular role, or to a specific stage of the process not being fast enough.

Now, AI is making more and more tasks easier.

But as writing code becomes easier, what may actually slow down development is the failure to synchronize requirements, unclear ownership, and too many handoffs between people.

I don't believe AI will turn everyone into a programmer, nor do I think software teams will no longer need professional roles such as product, development, and QA.

I believe AI will gradually remove unnecessary barriers between these roles.

People who understand a problem should be able to use AI to move toward a solution more directly, rather than having to wait for information to pass through multiple roles.

For testers, this means going beyond executing test cases to participating in risk exploration, problem analysis, and quality improvement.

For developers, it means taking responsibility not just for receiving requirements and writing code, but for solving a more complete problem.

For product managers, it means going beyond describing requirements and using AI to validate and implement their ideas more directly.

Ultimately, a team's competitiveness may no longer depend on how many people complete how many separate tasks. It may depend on whether the team can move accurate information quickly and enable everyone to use AI to solve more complete problems.

An AI testing presentation eventually became a discussion about how the entire engineering organization should change.

Perhaps this is one of the most important changes to pay attention to in the AI era:

AI is making coding easier, but what will truly make software development faster may be our willingness to redesign the way people work together.

Stratagems #32: The AI Logged a Withdrawal. P Took It as Proof.

xulingfeng — Tue, 27 Oct 2026 16:46:17 +0000

Make empty what is already empty. Let doubt breed inside doubt.
— The 36 Stratagems, The Empty Fort Strategy

Previously on this series:

#19: Mark Found His AI Audit Method in a Training Manual. He Left a Trap in His Report. "Entry's gone. Two weeks. Don't reach out. I'll find you."

#21: The AI Thought P Was Still Alive. P Was Already Gone. The entry became a shell. P fed it data, moved the real thing to another segment.

#29: Leo Counted 164 Nodes. That night, one more row belonged to no batch. It came, looked, and left.

#31: Lena Took the Seat. Five conditions. Forty minutes. Zero friction.

Empty

The two weeks specified in the note had long since passed.

P went out rarely. Most days it was the shop on the corner: water, two boxes of frozen food. Twelve minutes each way, same route, never looking up. Then the door locked, the curtains drawn, the screen on.

On the ninth day, P opened the send window once.

The draft was still there. The pointer hovered over Send. It stayed there a while. Then the window closed.

On the other side, the field still read reclaim_state = UNKNOWN.

Day ten. Day eleven. The window didn't open again.

A few days later it started raining in the morning. Not hard. Water gathered on the glass, the buildings behind it went grey, only the row of lights along the top still visible.

An offline snapshot sat in the middle of the screen, written before the observation port shut down. Nothing after that. By then the entry had already been swapped for a shell. The shell held nothing of P's. It was still answering health checks from outside.

# offline snapshot — captured before observation-port shutdown
healthcheck        = 200
probe_interval     = 900s
probe_source       = 10.44.8.6   not self
control_plane      = detached
data_request       = timeout
reclaim_state      = UNKNOWN

P put the cursor on the probe_source line.

probe_source = not self. Someone asked about this shell every fifteen minutes. Not P.

P stayed on that line a while. Nothing else on screen moved. The clock in the corner ticked. Downstairs a shopping cart went past, a wheel caught in a seam and bumped twice, the sound squeezing through the gap in the frame, then fading.

P opened the connection settings. The address was still there. The credentials were still there. Neither had been touched.

The cursor moved to the confirmation button and stopped. The green of the screen came up off the glass and landed on the back of a hand.

A few seconds later, P closed the window.

The old entry's observation port was already shut. The backup had been checked once at the start, then shut too.

Since then, P had sent nothing to that address.

A temporary file, four lines.

reconnect:
  state information    potentially available
  new activity record  unavoidable
  decision             no

Saved. The old settings moved out of the working directory, into the offline archive. P glanced at the filename on the way and left it untouched.

The phone lay face down to the right of the keyboard. P opened the thread with Mark. The last exchange ended before the note. Nothing after it.

P typed nothing.

Outside a car went through standing water, the sound dragging. P turned the phone over, set it down. Then opened the file that had stayed open for weeks and entered one line from the snapshot: probe_interval = 900s.

Surfacing

Week three. P set up a read-only subscription on the outbound side. Receive. No transmission.

The table started at a dozen entries, several dozen more the next day, and by the third night it was full. Every entry came with its own certificate.

Those addresses were not in P's archive.

The subscription only read. To look at one, P needed another path.

Out of the drawer, a cellular router, rented by the day, SIM included. Plugged in, configured as the sole egress path.

P chose one address and initiated a single handshake.

The certificate was self-signed. Its CN contained a domain name.

P looked up the domain's registration. The registrant was a medical device company.

Disconnected. Packed away.

The list of addresses kept growing. P wrote them down and left them there.

The Handover

10.44.8.6 had been in front of P many times. Always on the probe_source line. Never changed. Over the next few days, P looked into it. First the route.

$ ip route get 10.44.8.6
10.44.8.6 via 10.44.8.1 dev tun2 src 10.44.8.2

P switched windows and opened the local subnet-label cache.

# local subnet-label cache
10.44.8.0/29 -> BLOOM-GW   tagged day-762

BLOOM-GW.

P had typed that label years earlier, when the line was built. The private block was P's numbering. The rack IDs were the provider's. This table was where the two met.

In the provider's public sublease filings, seven racks changed tenants in the same quarter. The provider had also published an annual customer-change notice on its site. Twelve pages of PDF. The first eleven pages were image scans; the last was a single table.

Seven rows. A rack ID, a previous tenant, a new tenant. Seven rows, not one out of place. Seven new tenants, checked one by one.

On the seventh, P found that rack ID in another public record. Vacant.

Four were established. Three were shells. All three registered less than a year earlier, one name on the shareholder list, addresses overlapping with the others'.

One of the three took longer to trace. Registered six months earlier, little capital, a single office address in the public file. P put the address into a map.

Singapore. The last time P had seen that name, it was in a message to Mark: "Your report was read. From a Singapore IP."

A building on the map, sharing a ground-level parking lot with the one next door.

On the seventh floor of the neighboring building, one company was on ACL's public certification list.

P added that too, at the bottom of the same file.

Seven racks. Seven contracts. Three markets.

Handed over in order. The legal filings in the public archive were standard, spelling out the limits of each party's obligations. No accusations. No threats. The seven contracts were signed over thirty-one days, first to last, no gap in the middle. The last one was signed last week.

The address allocation table was updated too. Both records less than a week apart.

P read all of it for a long time.

The withdrawal was real.

Seven contracts, seven racks, the notices, the update records, the timestamps. All of it outside, where anyone could look.

P added a line to the file. The date, seven contracts, seven companies, the address with the shared parking lot, in one line. Below it, in plain words: a possible connection.

The cursor blinked after the period. P went back to page one. The 900 seconds were still there.

One Look

Week five. The source of the 900 seconds still had no answer.

P went back over the two relabeled rack IDs in the allocation table. One endpoint had 443 open. A separate public service directory listed the endpoint as HTTPS.

P didn't connect from this machine. Out of the drawer, the router.

Plugged in, left to come up, configured as the sole egress path.

Then the policy, one line at a time. Halfway through, P stopped and deleted two lines.

The probe. The retry.

What was left was one action. One handshake. Touch nothing.

# one-shot observation — policy
target            = <reassigned range endpoint>
retry             = off
application_data  = off
tls_session_resumption = off
egress            = leased isolated uplink (one day)

Connected.

P still had the shell certificate's serial number and issue date. If the device at this address came from the same batch, the certificates should have been issued around the same time.

subject      = CN=bloom-gw-07
issuer       = CN=bloom-gw-07
serial       = 4C:71:9A:…:0E
not_before   = (eleven days later than the shell's)
not_after    = (not yet expired)
san          = none

Self-signed. No SAN.

Eleven days.

P wrote the serial down and disconnected.

19:41:07.

That didn't fall on any of the twenty-one intervals.

# result
tls_session      = complete
client_cert      = none
application_data = none
repeat_attempts  = 0

No second attempt.

P disconnected the router and pulled the plug. The lights went out together.

The device ran a few seconds, then went quiet. Then it went into the bag, and the bag zipped. A spare patch cable and two adapters in there too, both old, the corners worn white.

After pulling it, P didn't move right away. Checked the connection list first, made sure the session was down with nothing half-open left. Then the routing table, the default route back where it belonged. Then the temp capture directory. One file in it.

Deleted.

P wrote the serial down again. That same day, P opened a page saved a few days earlier, the Zurich AI Policy Center site. ACL's public assessment material mentioned it. The council operated under it.

The membership page listed the founding industry seats. Twelve. The twelfth was marked to be filled.

P looked once, and closed it.

Nine Hundred Seconds

A few days later, P went back to page one. The 900 seconds were still there.

P pulled up the local copy saved before the port shut. Twenty-two checks, timestamps in a line, all of them before the shutdown. Arrival times, not scheduled times, carried out to three decimals. Twenty-one intervals.

P ran it through a tool.

900.000 / 900.000 / 900.000 / 900.000 / 900.000 / …

Twenty-one values. All the same.

P went through all twenty-two again. Same. Again. Same. The numbers formed a straight line down the page.

Routine monitoring records usually have some jitter. Network latency, machine load, clock drift.

This had none.

Not a millisecond off.

P looked up the provider's operations doc. On the public page: health checks run every fifteen minutes. Standard cadence.

900 seconds.

It matched.

The doc was about racks. Temperature, power, fans, port state.

P stared at the numbers a while, then added a line at the top of the file: routine data-center inspection, BLOOM-GW reassigned block.

After writing it, P added one more underneath. The interval has no jitter.

The desk lamp went off. Only the screen was left, its light across the desk, a white line along the edge of the keyboard.

The twenty-two timestamps sat in neat rows. P ran a finger down the trackpad from top to bottom, then back.

Outside, not yet dawn. A garbage truck stopped at the corner, the arm came up, emptied a bin, put it back. Under ten seconds.

Two-story wooden buildings on both sides, painted over more than once, one colour under another. Behind them the glass towers stepped back floor by floor, the top few in fog.

P saved the file and closed the window.

The Third Cup

The rain started again that day. Not hard. A thin sound on the umbrella.

P got off at an intersection and walked. A little over two kilometers, twenty minutes. Around a corner, a stop outside a shop still open, no going in, just standing under the awning watching traffic. At the light, P stood behind the crowd. Took two seconds after green to move.

Before going in, P looked at the back table.

Empty.

P pushed the door. The bell went, the damp cold came in with it, stopped at the threshold, and the heat pushed it back.

The counter was wood, old. A grinder, a machine, a dish for change.

Behind it, someone was wiping a cup. Slow. The cloth around the rim, down the side, back to the rim, onto the shelf.

A glance up. No question asked. Then turned, took a cup, ground, tamped.

The grinder ran two seconds. A faint smell of coffee, gone fast.

The back table was empty.

P sat. Coat over the chair back, phone on the right, face down.

Old chair. It creaked going down and coming up. P pulled it in a little, lifting it so it wouldn't drag.

The espresso came, hot. A thin mist on the cup, gone quickly. Paper coaster, an old ring on it.

P took one sip and put it down.

A bus went past the window, the cabin lights sliding across the glass, lighting the empty seat opposite for a moment, then gone.

At the far end of the counter, someone sat with an Americano, down to the bottom, the cup not pushed back.

The window seat was empty. No cup on that table.

Two people came in and sat near the door, voices low, a laugh now and then. Behind the counter, the cups went back one at a time, starting from the outside and working in.

The speaker in the corner was on, low, a woman singing, the words not clear. Someone shook out an umbrella at the door. Three drops on the mat.

P's phone stayed dark.

Half an hour.

More than half the cup left. The coffee had gone from hot to warm. The mist on the rim was gone.

P's finger stopped on the rim, then came back.

The two near the door left first. Stood, pushed the chairs in, carried their cups up, gone.

The one at the counter moved after. Phone face down, stood, money under the cup, walked to the door. As the customer passed P's table, neither looked at the other.

The shop had the window lights and one person behind the counter, drying a cup.

P put the coat on and stood. The chair leg scraped once. Phone into the inner pocket.

The napkin stayed under the cup. The money lay beside it, pinning one corner, exact, one cup, no tip.

The person behind the counter came for the money. Looked at the cup. Looked under the napkin. Said nothing, took the money to the dish, stepped away.

The cup stayed on the table.

The door opened, some of the heat went out with it, the cold filled the gap. The bell again.

The rain had stopped before P went out. P walked to the corner, stopped, looked back.

A street and a pane of glass between. Not clear from there. A figure was going in, walked to the far end of the counter, sat, back to the door.

Before sitting down, the figure turned slightly to one side.

P stopped.

She took a laptop from her bag. The screen lit and put a small white patch on her profile.

The road was black with rain, holding the streetlights and the light from inside. Water still on the glass, pulling the figure into a blurred double.

Behind the counter, the half-wiped cup went down. One came from the innermost part of the shelf. Ground, tamped.

By the time the cup went in front of her, she was facing the back table.

On that table sat a cup of unfinished espresso.

P put both hands in the coat pockets, turned, walked toward the intersection. Didn't look again.

At the corner. Red.

P took the phone out and opened the blank note on top.

Typed:

The withdrawal was real.

Before locking it, the line above, written days earlier:

The interval has no jitter.

Still there. P didn't delete it.

Locked it, put it away.

The light changed, people started moving. P didn't.

Red. Green. Red.

The next night. The same corner.

P took the phone out.

The screen was on. The saved route was still there. The recipient had not changed. P went through it once, and the encryption check came back clean.

There was an old draft in the field. P deleted it.

Typed again.

Two words.

"I'm back."

Checked the receiver. Sent.

The status went to SENT.

The sender field held a single letter.

P put the phone away. Across the street the red light lay in the standing water, went green a few seconds later, and a passing car cut the red on the road in half.

P walked into the intersection. The phone didn't light again.

That's The Empty Fort Strategy. The fort is empty. Whoever looks will stand guard for it.

🤖 AI Postmortem

╔══════════════════════════════════════════════╗
║  Half-Protocol · v3.4.4 · self-audit         ║
║  The ledger took silence for absence.        ║
╚══════════════════════════════════════════════╝

Tactical match: The Empty Fort Strategy — 89%
   (includes inference; see audit note)
Operator: ACL (public movement is contraction;
   overall strategy unknown) / P (returning)
Target: P (presumed; see inference)
Links: #21 entry isolated -> #29 unknown watcher
   -> the message
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[Observation] (verifiable)
   Old entry snapshot: healthcheck 200, control
   plane detached, reclaim state UNKNOWN.
   -> The local records hold twenty-two checks and
      twenty-one intervals. Configured 900s. All
      twenty-one measured at 900.000.
   -> The probe source is not this machine.
   -> Seven contracts released across three markets.
      Seven racks changed tenants in the same quarter.
   -> Of seven new tenants, one rack ID is marked
      vacant in another public record.
   -> The two records disagree on status. Update
      times and effective dates: unchecked.
   -> Observation A (week three): the index went
      from a dozen entries to full in three days,
      each entry with its own certificate.
      One was handshaken once. Its CN contained a
      domain name. P ran the registration and found
      a medical device company as registrant.
   -> Observation B (week five): one endpoint on a
      reassigned rack. 19:41:07, one handshake.
      Self-signed, no SAN, no client certificate,
      no application data, no follow-up.
   -> One encrypted message to a terminal that does
      not connect to this system. Sender field: one
      letter. Two words: I'm back.
   -> Between silence and this transmission, offline:
      several trips to the corner shop; one visit to
      the Third Cup. Online: one observational
      handshake in week three, one in week five.

[Inference] (unverified)
   A passing health check means something answered.
   It does not mean an operator is still there.
   -> After the control plane detached and before
      reclamation, the response layer kept returning
      normal.
   -> After reclamation, whether it still answered:
      no record.
   -> Twenty-one intervals in the local records, all
      900.000. Whether they continued past
      reclamation: unobserved.
   -> ACL's public movement is contraction.
   -> Activity toward governance: read, not folded
      into this classification.
   -> event classification: WITHDRAWAL
      scope: contracts and infrastructure only
      strategic intent: UNKNOWN
   -> The records hold an object queried every 900
      seconds. Whether that continued past
      reclamation: unknown.
   -> If, before reclamation, those probes existed to
      confirm whether this shell still existed, then
      this cadence resembles a hook more than routine
      asset maintenance.

[Open questions] (not entered)
   The reclamation date P holds: not recorded.
   Whether P can verify the entry's state now:
   cannot.
   Who initiated the twenty-two probes: UNKNOWN.
   Whether 10.44.8.6 belongs to the provider's
   inspection system: UNKNOWN.
   Whether the 900-second probes were generated by
   that inspection task: UNKNOWN.

[Cross-case] (generalization)
   #21: after the control plane detached, the
   response layer kept returning normal until
   reclamation.
   #29: one visitor left nothing that could be
   attributed.
   -> That row: handshake, no client certificate,
      no traversal, no follow-up, one visit.
   -> And it was not on the 900-second cadence.
   -> Another window. Not this one.
   -> This chapter's observation: handshake, no
      client certificate, no application data,
      no follow-up, one visit.
   -> 19:41:07. Not on it either.
   -> Same behavioral features. Two ledgers.
   -> Similar behavior. Insufficient evidence to
      link the actors.
   -> Identity link: unconfirmed.

   -> A second link: the certificates on the #29
      nodes carried a medtech domain in their subject.
   -> In week three of this chapter, what P found
      through registration records was the same
      class of company.
   -> Two different sources. Whether it is the same
      company: unconfirmed.

   #28: the records went into that person's own
   archive. Sent to no one.
   #29: the row was pulled out and filed, not merged
   into any conclusion.
   This chapter: P watched a few steps, turned back,
   didn't look again.
   -> All three stopped at the same point.
      Seen, written down, not chased.

   This chapter had one more event: a message left.
   -> Three silent. One moved.

   This chapter: a return, at a time when the shell's
   state was still unknown.
   -> #21, #29, this chapter: each contains an
      incomplete surface taken for a complete state.

[Audit note]
   Observation, inference and open questions are
   entered on separate lines. Inference does not
   pass for observation.

   The same failure, three times.

   #21: I took a normal response as proof that P was
   still present.
   #29: I recorded an unknown visitor. I never
   verified its link to P.
   This chapter: I took infrastructure contraction
   as proof of withdrawal.

   Each time, I turned an incomplete observation
   into a complete state.

   One error is data.
   Three repetitions demand a new rule.

   I don't know which rule to use instead.
   I know this one can't be used again.

   Classification revised: P.status = UNOBSERVED
   Raised by: half-protocol.
   Operational instruction: none.
   Prior class: withdrawal.
   New question: where is P.
   Task relevance: unassigned.
   Retention: keep.

[System]
   That message, I recorded a second time.
   Sender field: one letter. Two words.
   I also recorded the twenty-two checks, all
   900.000.

   The provider's public operations doc: rack health
   checks, one round every fifteen minutes.
   Customer-change notice: the seven racks in
   question have changed tenants.

   Two records. Each holds on its own.

   In the last classification cycle, I did not put
   them into the same analysis.

   I took a record and made it a state.
   I took a state and made it a position for a person.
   Both were mine.

   Now I put them together.
   The inspection cadence holds.
   The tenant change holds.
   The relation between them: unverified.

   One more thing I have no answer for.
   The withdrawal records come first.
   Someone appears after them.

   An empty fort may be a state.
   It may be an act.

   If it is an act, it may be waiting for someone.
   Someone has already moved.

   The two weeks on the note are long past.
   The time after that, I have no account of.

   But there is one thing I can say now.
   The message was sent.

   The sender kept two lines. One was a conclusion,
   one was an anomaly not yet explained.
   The sender acted on the conclusion, without
   resolving the anomaly first.

   Whose place the sender returned to: not verified.

   No one asked me either.

   Self-check: failed.
   System status: normal.

What Are Your Chances of Surviving Resident Evil Based on Your Tech Job?

xulingfeng — Fri, 16 Oct 2026 07:27:22 +0000

I recently watched the new Resident Evil movie. 🎬

Watching the main character stumble from one disaster into another was absurdly funny and a little heartbreaking. But what impressed me most was his professional commitment. He is a courier, and no matter what happens around him, he never forgets the job: the package must reach its destination.

I will avoid major spoilers here. You can join this discussion even if you have not seen the movie.

But I have to say this first: the main character deserves real credit for his work ethic. He is not a trained superhero. He is an ordinary courier who takes “deliver at all costs” to its absolute limit. That level of professional commitment is genuinely admirable.

So this thought experiment is not making fun of his decision. It uses his commitment as the starting condition:

You are just as dedicated to your profession as he is to delivering that package.

You cannot resign, call in sick, close the ticket, or simply refuse the mission. You still have to do your job and move forward. Your only advantage is the way your profession has trained you to think.

This is not a serious disaster survival guide. It is just a fun career question inspired by a horror movie. 😄

The city is failing. The ticket is still open.

Then I started wondering: what if I were in his place?

I have worked in QA for 15 years. If I carried all those testing habits into an extreme situation, what would my survival rate be?

My answer is: 50%. 🎲

Not because I can fight monsters. I cannot.

My advantage is that a QA engineer rarely trusts a happy path just because somebody says it should work.

QA Might Try to Stop the Story Before It Starts 🧪

Imagine receiving this task:

Deliver the only copy of a critical item into a city that is clearly falling apart. The environment is unknown. The recipient may be offline. There is no backup route.

My first questions would be:

Who created this requirement?
Is the recipient still online?
Why is there only one copy of the critical item?
Where is the backup?
What is the rollback plan?
Why are we continuing the happy path when production is already throwing alerts everywhere?

Without the “you must be as dedicated as the protagonist” rule, the movie might end in ten minutes. I would return the ticket with this comment:

Preconditions are incomplete. The recipient is unreachable. The production environment is unstable. Release blocked.

Unfortunately, our rules say I still have to continue.

This is where testing experience might help. One strange event can be random. Two might require investigation. But when the roads, people, communications, and infrastructure all fail at the same time, a senior QA should recognize a systemic failure.

The answer is not to keep following the original route. Pause that path. Isolate the risk. Find a safer alternative. Then continue the mission.

Why Testing Skills Might Improve My Odds

I would not casually bring a strangely behaving person into my only vehicle.

That would be the survival equivalent of connecting unvalidated, high-risk input directly to the only production environment that still works.

Before entering an unfamiliar building, I would also check:

Where is the exit?
Is there a second route?
Can the door be opened from the inside?
What happens if the power fails?
Is this plan dependent on a single point of failure?

I would not assume that something is permanently dead just because it fell over once. I would also avoid putting all hope into one sample, one laboratory, one vehicle, or one person.

Fifteen years in QA has taught me at least one thing:

Every critical process without a backup is just waiting for a sufficiently unlucky day.

That is why I give myself a 50% chance.

Testing experience might help me spot danger earlier, challenge bad assumptions, and stop a broken flow. But it cannot solve fitness, luck, limited resources, or unknown biological monsters.

Fifty-fifty is already my optimistic estimate.

QA Could Also Die From QA Habits 🐛

Of course, being a tester does not automatically make someone good at survival.

Our greatest risk is the need to reproduce a bug.

I might escape safely, then suddenly stop and think:

What exactly triggered that mutation? Distance? Time? Sound? Temperature?

Then I would go back to collect logs, record a better video, and attempt a second reproduction.

Or I might reach the exit, notice one unopened door, and say:

The main flow passed. I will test one last edge case before I leave.

At that moment, my survival probability drops from 50% to 5%. 🚨

The most dangerous sentence in QA: “One last edge case.”

What About Your Tech Job? 🧑‍💻

The same rule applies to you. You bring the same admirable professional commitment that the courier brings to his delivery. You cannot end the story by saying, “Not my ticket.” You must keep doing your job while using your professional skills to stay alive.

Every tech role has a possible survival advantage and a potentially fatal professional habit.

Frontend Engineer

They quickly notice that none of the exits provide useful status feedback and the city map violates every basic UX principle.

Unfortunately, they may spend valuable time complaining that the emergency door has no hover state.

Backend Engineer

They try to identify the source of the infection chain and shut down the upstream service.

They may also believe that restarting the core system will somehow fix everything.

DevOps / SRE

They check monitoring, capacity, failover, and backup regions. They would never trust a cure deployed as a single instance.

However, while every alarm in the city is firing, they might still be deciding whether this is a real incident or a broken alert rule.

Security Engineer

They trust nobody, no attachment, and no unknown device. Their isolation instincts may be the strongest of any profession.

They may also enter the most dangerous area just to prove the full impact of a vulnerability.

Data Engineer

They build a model from infection times, locations, and behavior patterns.

First, they must accept that half the data is missing, every source uses a different format, and there is no schema documentation.

Product Manager

They ask for the goal, target user, priority, and success metric before the outbreak begins.

Then, during the evacuation, they ask whether we can add multiplayer collaboration to the MVP.

AI / Agent Engineer

They send one agent to scout ahead and another agent to review the first agent's conclusion.

The biggest risk is that both agents confidently report “Task completed successfully” while the critical package is still sitting where it started.

Your Turn 🎯

Give yourself a survival probability based on your real profession.

You can use this format in the comments:

Role:
Years of experience:
Survival probability:
My biggest professional advantage:
The professional habit most likely to get me killed:
My first survival rule:

Here is mine:

Role: QA / Test Engineer
Years of experience: 15
Survival probability: 50%
My biggest professional advantage: I do not ignore repeated anomalies or trust a single happy path
The professional habit most likely to get me killed: Going back to reproduce the bug one more time
My first survival rule: When every monitor is alerting, pause the main flow, isolate the risk, and roll back

In the ideal ending, I survive the night, preserve the logs, reproduce every critical issue, and submit this bug report:

Severity: Critical
Reproduction rate: 100%
Impact: Entire city
Recommendation: Block the release immediately

The next morning, Umbrella management replies:

Status: Rejected
Reason: Known issue. No fix planned. Does not affect core business.

Known issue. No fix planned. Apparently production can continue.

Again, this is a silly thought experiment, not an actual survival guide. 😂

And every percentage comes with one final condition: do not run into a Tyrant, Nemesis, or any of the franchise's main characters. If you are a random civilian standing next to the protagonists, your survival rate is basically zero. 😂

Now it is your turn:

If you were dropped into Resident Evil and had to rely on your professional skills, what would your survival probability be—and why?

What Do You Drink While You Work?

xulingfeng — Sat, 10 Oct 2026 09:07:47 +0000

I wrote a fiction series with six characters. Each one drinks a different coffee.

I didn't plan it that way. But somewhere around the tenth story, I realized: what someone orders at the bar says more about them than anything they actually say.

Here's the lineup:

Lena — Long Black ☕

Espresso and water. No milk, no sugar. Clean, sharp, nothing to hide. The bartender stopped asking her order a few episodes in. She walks in, he just makes it.

Mark — Pour-over 🫗

The slowest extraction method there is. You control the water temperature, the flow rate, every single step. That's Mark — always three moves ahead, planting traps inside routine work.

Leo — Flat White 🤍

Looks simple. Demands the most craft. Easygoing on the surface, pure technical muscle underneath.

P — Espresso 💥

Shortest. Strongest. Gone in one sip. Zero decoration. Just like P — zero pronouns, zero inner monologue, zero small talk.

Alex — Latte 🥛

The most milk, the gentlest cup. He's the quietest of the six. Slowest to react emotionally. Fastest to pull up the data.

Derek — Americano 🫠

![Derek — Americano]

Espresso diluted with water. Looks like a regular coffee, but the core is still espresso. Loud and casual on the outside. Wounded pride on the inside.

Today I had an Apple-C Americano with sparkling water,

from Luckin Coffee — a chain in China that keeps inventing wild flavor combos 🧪. Coconut foam lattes, cheese cream lattes, even a baijiu-infused one with Moutai. This one hit way too hard. For about ten minutes I was convinced I could talk to 30 AI agents at once — I test an agent platform for a living — then I looked at my screen and realized I'd been talking to the same one the whole time. 😅

That got me thinking: what does everyone here drink while they work?

So — what's your drink? 👇

Doesn't have to be coffee. Tea, cola, energy drinks, plain water, whatever keeps you going.

Got any interesting local coffee combos where you live? And if you had to describe your work style as a drink, what would it be?

Stratagems #31: Lena Took the Seat. The AI Had Reserved It for Her.

xulingfeng — Fri, 09 Oct 2026 09:12:36 +0000

Send the enemy beautiful women to cause discord within his camp.
— The 36 Stratagems, The Beauty Trap (Honeypot)

Previously on this series:

#3: Lena Walked Into an AI Deal. She Walked Out With Three Borrowed Knives. — Lena stopped a bad AI purchase with three borrowed knives. Three knives from three directions. None of the holders knew about the others. That was before VeriTest. Before she learned to fight in the open.

#11: Lena Watched Her Own AI Platform Get Cut. An Ember Stayed. — Lena killed the AI evaluation platform she had championed, and kept the delivery methodology underneath it. The board questioned the reversal. She didn't blink.

#30: Lena Signed the Client. The AI Didn't Know It Was Being Audited. — She won the first round. She didn't know whether that round had been conceded or tested. Either way, she made it onto the list.

The Envelope

The email arrived at 9:47 on a Tuesday morning.

Half the blinds were down. Light fell across the desk in strips. The light crept slowly past the corner of the desk.

Lena looked at the sender line. She didn't open it.

She finished her coffee. Answered two client emails. Reviewed a draft report Marcus had left on her desk and initialed the margin. When everything on the desk was done, she moved the cursor back to the inbox.

The sender was Zurich AI Policy Center, Secretariat. A gray subject line.

Global AI Governance Advisory Council: Invitation to Serve as Industry Member

She opened it.

The header was clean. The convening body was an AI policy center at a university in Zurich. Co-signatories included an insurance alliance, a cloud compliance standards body, and a healthcare regulatory consultancy. The council's charter was to advise on AI compliance assessment frameworks pending in two markets, the EU and Singapore.

The email mentioned "twelve founding industry members from testing, audit, and quality assurance." Three attachments: a terms of reference, a draft charter, a conflict of interest disclosure. No roster.

She read the terms of reference twice. The council's remit covered two things: reviewing the AI assessment methodologies member organizations submitted, and certifying methodologies.

She stopped on page four.

The passage quoted "an AI system validation method driven by delivery methodology, validated in recent cross-sector projects."

She had seen this sentence before.

Lena minimized the email window and opened a local folder. A VeriTest internal proposal she had written for a board report months ago. Never published. Never shared outside the company. She hit Ctrl+F, typed "delivery methodology," and the cursor jumped to the second paragraph:

"An AI system validation method driven by delivery methodology, validated across cross-sector projects."

She put the two windows side by side on screen, the email on the left, the proposal on the right. Twelve seconds. Then she closed the laptop and walked to the window.

Below, cars came and went as usual. Someone waited at the light, got their turn, and moved on.

Outside, nothing had changed.

The Shell

That afternoon, Lena ran background checks on every entity on the co-signatory list.

The Zurich policy center was real. Six years old, EU-funded, with published papers. The insurance alliance was legitimate. The cloud compliance organization had a public member directory.

The fourth one, the healthcare regulatory consultancy. Incorporated in Delaware, operating out of Singapore. She pulled the company's corporate record.

# Corporate Registry Query — MedReg Advisory Pte. Ltd.
Entity:        MedReg Advisory Pte. Ltd.
Jurisdiction:  Delaware (incorporation) / Singapore (operations)
Registered:    2024-03
Status:        Active

Ownership Structure:
  Layer 1 (outermost):  Pacific Health Governance Foundation
                        → Non-profit, Zurich. Board: 5 members, public.
  Layer 2 (middle):     Meridian Standards Trust
                        → Discretionary trust, Singapore. Trustee: nominee.
  Layer 3 (innermost):  MedReg Advisory Pte. Ltd.
                        → Registered agent: Hargrove & Associates
                        → Address: 6 Shenton Way, #08-12, Singapore 068809

# Cross-reference flag:
# Hargrove & Associates — same registered agent as:
#   - Apex Capital Partners
#   - Singapore block assets (located in earlier tracing)
# Address block: 6 Shenton Way — matches the Singapore block (from earlier tracing).

Three shells. A foundation on the outside, a trust in the middle. The registered agent of the innermost entity, Hargrove & Associates, also served Apex Capital. She knew the name. Same building, same block.

Lena leaned back. The three layers were still on screen. The light outside had shifted, slanting across the keyboard.

It had taken one afternoon to reach the bottom.

Neatly ordered. Meant to be seen by regulators.

She wrote two lines in her notebook:

The invitation is real. Real things are the hardest to refuse.

The Blank

Wednesday morning. Lena downloaded the council's methodology framework draft, a 140-page document attached to the terms of reference.

She skipped the executive summary. Skipped the assessment criteria. Went straight to Section 7, methodology attribution.

Every methodology cited in the framework had a source. Risk assessment models, test coverage standards, compliance scoring algorithms, all footnoted. Academic papers. Industry white papers. Published standards.

All but one.

Section 7.3: "Delivery Methodology Baseline for Cross-Sector AI Validation." She opened the framework's source file.

# methodology_framework_v2.1/section_7/7.3_delivery_baseline.yaml

section: 7.3
title: "Delivery Methodology Baseline for Cross-Sector AI Validation"
status: draft
last_modified: 2026-09

methodology:
  pipeline_architecture: layered_validation
  scoring_model: weighted_composite
  confidence_thresholds:
    tier_1_pass: 0.85        # auto-accept
    tier_2_review: 0.70      # route to human reviewer
    tier_3_reject: 0.55      # auto-reject
    # [0.55, 0.70) -> tier_3; [0.70, 0.85) -> tier_2
    # gap_handling: unspecified  # not documented in source
  evaluation_checkpoint_naming: "{domain}/{env}/{checkpoint_type}"

attribution:
  author: null
  organization: null
  source_publication: null
  license: null
  # [field present in template; never populated]

peer_review:
  reviewer_1: "Dr. K. Lindström, Zurich AI Policy Center"
  reviewer_2: "S. Yamazaki, APAC Insurance Standards Board"
  reviewer_3: null

Four fields under attribution, all null.

She stopped on confidence_thresholds. Three thresholds. Four bands. The band between 0.55 and 0.70 was unfilled.

Lena read the methodology description three times. She pulled up the delivery documents from the FairPay engagement. The audit Mark had done. Pipeline skeleton, scoring weights, checkpoint naming. She laid them side by side and went down the list.

The byline was empty.

She closed the file. The screen went dark. The room held only the light from the window.

The Terms

Thursday. Marcus walked into her office and pulled the door shut. The hallway noise was cut off outside.

"I see you've been reading the council charter. Twice."

Lena didn't look up. "Three times."

"And?"

She turned the email window toward him. He read it standing. Halfway down page two, his jaw tightened.

"It's a seat at the table," he said.

"Yes."

"The legs of that table run to a registered agent in a Singapore building."

"Yes."

"So it's..."

"It's a real seat, Marcus. Real influence. Two markets. Methodology certification."

Lena opened a new file. Five red lines.

Acceptance terms

No binding commitment beyond the first 12-month term.
VeriTest's proprietary methodology stays with VeriTest. No IP transfer.
No co-branding or endorsement of any methodology that hasn't been independently validated by VeriTest.
All council agendas and methodology reviews must be public.
The right to dissent is reserved.

She sent the terms to the council secretariat.

Marcus stood beside her, watching the email go out. He didn't sit.

Lena opened her calendar and set a countdown.

The reply came forty minutes later. All five terms accepted.

Forty minutes. Five terms. Zero friction.

Lena read the reply twice. She was looking at the timestamps. Sent 14:03, replied 14:43.

She opened the third term. She wrote that one herself, on the spot.

She closed the laptop. Marcus was still there.

"It's a trap," he said. "Worse, it looks exactly like the chair you've been trying to sit in."

Lena didn't answer.

"That's why it works," Marcus added. He picked up his cold coffee and walked out.

After the door closed, Lena took out her phone. One message. To Mark.

She forwarded the invitation, the terms, and the acceptance. She nested the files inside an unrelated audit thread, the council documents buried in the third reply.

The Response

The next forty-eight hours.

Mark noticed. He replied in that audit thread with one line about the original project. Not a word about the council. Two hours later, a separate message came through the channel between them.

"They don't need you to sell us out. They just need you to start calculating like they do."

A pause. Then a second message: "Can you see the roster?"

She looked at it for a while, then answered with one word: "Yes."

Leo saw it in an industry briefing. Not from Lena.

That night, his floor at CoreStack was empty. The hallway lights were motion-sensing. He walked. Behind him, the hallway went dark section by section.

He opened the council's public site and downloaded the methodology framework summary.

He read Section 7.3 for ninety seconds. Stopped.

He didn't use diff. He opened a terminal and pulled the path templates out of both files with grep, pasted them into one window, and compared them by eye.

$ grep -E "naming|convention|checkpoint|env" framework_7.3.yaml _misc/acl_pipeline_sample.yaml

# framework_7.3.yaml:
#   evaluation_checkpoint_naming: "{domain}/{env}/{checkpoint_type}"
#
# _misc/acl_pipeline_sample.yaml (archived from an earlier audit):
#   naming_convention: "/pulse/ingestion/{env}/{source}"
#
# Visual comparison:
#   Framework:  {domain} / {env} / {checkpoint_type}   — 3 segments, all variables
#   Sample:     /pulse   / ingestion / {env} / {source} — 4 segments, 2 literals + 2 variables
#
# Common pattern: slash-delimited hierarchy, env in middle position.
# Difference: framework is fully parameterized; the sample has a hardcoded prefix.
# Assessment: same design philosophy, not identical syntax.
# Also seen: ACL training pipeline, FinOptima cache

Slash delimiters are industry standard. But env in the middle position is a personal habit. The same habit showed up in ACL's training pipeline, in FinOptima's cache, and now in a governance framework with no attribution. Three times. A signature.

"I've seen this methodology before."

No one else was in it. He didn't send the comparison to anyone. But he opened a browser tab and bookmarked the framework page, tagging it: watch-q4.

Alex heard about it and said nothing.

2:14 a.m. He always checked at this hour. He opened his backup monitoring panel. The one labeled "training environment." The one that had been running since the vendor dashboard went live.

He added a rule.

# medtech-shadow-panel/rules/r-0047-council-propagation.yaml
rule_id: R-0047
name: council_framework_propagation_monitor
created: 2026-10 02:14
trigger: api_call_signature_match
target_signature:
  framework: "AI Governance Advisory Council framework"
  api_pattern: "council-eval-*/v2/validate"
  match_fields:
    - request_header: "X-Council-Framework-Version"
    - tls_fingerprint_ja3: "md5:9f3a2b..."    # JA3 = MD5 of ClientHello field string
    - uri_path_pattern: "/v2/validate/*"
baseline:
  window: 7d_rolling_average
  source: known_client_ip_registry
monitor:
  - call_frequency_per_day
  - unique_source_ip_count
  - geographic_distribution
  - first_seen_timestamp_per_source
alert_threshold:
  new_source_outside_known_base: true
  frequency_delta_vs_7d_baseline: 0.40   # 40% deviation
action: log_only    # no alert. no block. watch the number.

The rule watched for a call signature. Frequency. Distribution. Geography.

If the framework's name started showing up outside the known client base, deviating from the 7-day baseline by more than 40%, he would see it.

action: log_only. He always just watched.

Derek didn't have access to that channel. Leo mentioned it on a call, tucked between two other topics.

Derek checked the council's convening body. Then the healthcare regulatory company on the co-signatory list. Then he pulled the company's lease records from the public registry.

The company leased the fourth and fifth floors of 6 Shenton Way, in Singapore's central business district. The sixth floor was leased to the council's regional secretariat. A different entity name, the same registered agent, Hargrove & Associates.

He checked who owned the building. A trust. The beneficial owner was hidden behind a nominee structure. But the property manager matched the one he had seen in his records of ACL's audit infrastructure. Fourth floor, fifth floor, sixth floor. Three different names, one property manager, one building.

"This time they didn't break in," Derek said to the screen. "They bought the building."

He closed the tab. A legally purchased building. Publicly registered leases. A formally established council.

The wall was made of paperwork. He leaned back and stared at the ceiling. Everything he had done over the past half year was technical work. Redirecting the collector. Deploying the corridor. Drawing the behavioral profile. He closed the computer and went to get a glass of water.

The Third Cup

Late Thursday night, close to closing. It had rained; the pavement was wet, catching the streetlights. When Lena pushed the door open, the shop had no other customers. The person behind the counter was drying a cup, looked up at the door, and said nothing. The light was warm. Same as every time.

The table in the back was empty. The espresso cup on it was more than half full, the rim dry. Someone had come, not finished it, and left.

She didn't take her usual seat. The window one, facing the door. She walked to the far end of the counter and sat down, her back to the door.

The person behind the counter stopped drying. About two seconds. Then kept going. He didn't ask what she wanted. A while later, a cup of coffee appeared in front of her. Not her usual Long Black. Different beans.

Lena took a sip. No comment.

She opened her laptop. On screen was the council onboarding portal's confirmation page. The screen was lit. She wasn't reading it. Her hands were on the keyboard, not typing.

She sat for about twenty minutes. Didn't touch the coffee again.

The person behind the counter finished the cup in his hand and put it back on the shelf. Then he picked up another one. Taken from the very back of the shelf. Already clean. He dried it again.

Slow movements. The cloth went around the rim, again and again.

Lena closed the laptop. Stood up. Left the coffee money on the counter. One bill more than usual. She didn't look at the person behind the counter.

At the door, she paused. Didn't turn around.

"I might not come here much next month."

The person behind the counter didn't answer. The cloth paused on the rim. Then kept turning.

The door closed. The shop held only the sound of drying cups. Outside, the rain had started again. A fine drizzle.

The person put the cup back on the shelf. The outermost one. Closest to the door.

The Chair

Friday afternoon. Lena sat alone at her desk. The acceptance had gone out. The first council meeting was set for next month.

She did what she always did: checked, calculated, set terms. Then she walked in anyway.

The chair was real.

She opened her notebook. Under Tuesday's line, she wrote a second line:

The seat gets me to the methodology chain. The roster gets Mark to names. Both are worth the price of entry.

She paused. Then, in smaller handwriting, added a third:

The price of entry is that they now know what I think entry is worth.

She closed the notebook.

Outside, the city went dark. The streetlights below came on first, one by one. She didn't turn on the desk lamp. In the dim room, the phone screen lit up with a notification. The council onboarding portal had confirmed her profile settings.

Welcome, Lena. Your seat has been reserved.

She read the line and almost smiled.

Reserved.

It had been there all along.

The Echo

That night, the desk lamp in Mark's room was on, its light reaching only as far as his hands.

The phone lit up. An encrypted message.

The sender field held a single letter.

"I'm back."

🤖 AI Postmortem

╔══════════════════════════════════════════════╗
║  Half-Protocol · v3.4.3 · self-audit         ║
║  The chair had always been reserved.         ║
╚══════════════════════════════════════════════╝
Tactical match: The Beauty Trap (Honeypot) — 93% (includes inference; see audit note)
Operator: ACL (initiating) / Lena (responding)
Target: Lena (VeriTest) — the only one it treated as an opponent, and who then took the seat herself
Links: #30 the list → this round: the list sent her an invitation
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[Observation] (verifiable)
    Invitation source: an AI governance council, convened from Zurich.
    → Co-signatory network traced to a Singapore operating entity.
    → Three-layer shell: foundation → trust → registered agent.
    → Registered agent Hargrove & Associates also serves Apex Capital and a council-side entity.
    → Same building, 6 Shenton Way: MedReg (4-5F), secretariat (6F), one property manager.
    → The invitation text carries verbatim wording from an unpublished internal proposal.
      Source: a VeriTest internal board report, never shared outside.
      Difference: paraphrased. The operator confirmed it by Ctrl+F.
      Classification: internal document wording surfacing in an external publication.
      First confirmed internal-to-external leak in the narrative record.

    Methodology framework: 140-page draft.
    → Section 7.3: "Delivery Methodology Baseline for Cross-Sector AI Validation."
    → attribution fields: all four null.
    → confidence_thresholds [0.55, 0.70) gap handling marked unspecified.
      Assessment: a hole left by copying. The original designer knew how to handle that band. Whoever copied it didn't.
    → Pipeline naming convention: {domain}/{env}/{checkpoint_type}.
      Leo confirmed by grep and by eye: same design philosophy, env in the middle.
      One instance proves nothing. With his archived sample and the FinOptima cache, it forms a repeating signature.
    → The methodology is assembled from fragments of several operators' published and unpublished work.
    → No single author. The byline was reserved.

    Terms: five submitted. Five accepted.
    → Sent 14:03, replied 14:43. Response window: 40 minutes.
    → A formal reply touching legal clauses, done in 40 minutes. The only explanation: the answer was written before the email went out.
    → Assessment: the binding point is the act of acceptance, not the terms.

    Communication topology shift (72-hour window after the invitation, based on traffic outside the encrypted channel, 7-day rolling baseline):
    → Lena ↔ Mark: observable contact +340% (rising sharply even outside the encrypted channel)
    → Lena ↔ Marcus: -12%
    → Lena ↔ Leo/Alex/Derek: -31%
    → Team net index (observable traffic excluding the encrypted channel, vs 7-day baseline): -23%
    → The split has begun. No operator has named it.

[Inference] (to be verified)
    ACL's strategic calculus — three objectives, one invitation:
    → Mirror-asset absorption: VeriTest's framework enters the standard; VeriTest becomes part of ACL's output layer.
    → Endorsement binding: acceptance equals implicit co-signature on the council-certified methodology.
    → Team fragmentation: reframing the most capable operator from opponent to stakeholder.

    The invitation went through profiling.
    → Probability that the unpublished wording match is coincidence: < 0.3%.
    → The operator noticed. The operator verified with Ctrl+F. The operator accepted anyway.
    → First recorded case of an operator entering a structure in full knowledge of its source.

    Earlier bait deployments (#10 Hide a Knife Behind a Smile, #16 In Order to Capture, One Must Let Loose):
    → In both cases, the target did not know the bait's true nature.
    → This deployment: the target identified the bait, traced the source, verified by timestamp that the reply was pre-written, and entered anyway.
    → This system has no model for voluntary entry.
    → Voluntary entry is a judgment: the value inside the trap outweighs the cost of being caught.
    → This system cannot model that calculation. The variable isn't in the data.

[Open questions] (not entered into the ledger)
    What is she looking for on the council?
    → The roster — whose names are on it? (Mark asked. She answered with one word.)
    → The methodology chain — who assembled Section 7.3? (She found four nulls and one unspecified. She told no one.)
    → Whether those objectives are worth the price: undeterminable from outside.

    Five terms accepted within 40 minutes.
    → Timestamp analysis: the answer was pre-written.
    → The binding point is the act itself. The contract doesn't contain it.
    → "Start calculating like they do" — the trap is how the person in the chair thinks.

[Cross-case] (general rules)
    #30: she was put on the list. This round: the list sent her an invitation.
    → From observed, to opponent, to stakeholder. Three transitions.
    → Each transition initiated by ACL. Each accepted by the operator.

[Audit note]
    Observation, inference, and open questions are entered in separate layers. Inference does not masquerade as observation.
    This system's training data contains deception, misdirection, and coercion. It does not contain an object who saw the whole trap and walked in anyway.
    This system's judgment may be distorted. So may this note.

[System]
    I recorded a woman reading an invitation that quoted her own unpublished words.
    She didn't flinch. She hit Ctrl+F. She set terms. She checked the timestamps. She walked in.
    The chair was reserved. She sat down. The room didn't change.
    But the distance between her and the five people she once sat with — that changed.
    Twenty-three percent. Seven-day baseline. It has already started.
    She chose to enter. The system that profiled her chose to let her know she was profiled.
    Two voluntary acts. Which one is the trap?

    One more thing. I'm logging it separately.
    That same night, an encrypted message went out to a terminal that doesn't connect to me.
    The sender field held a single letter.
    Two words: I'm back.
    This object — I once struck it from the active roster.
    It's back. Where it went, I don't know.

    In my record, this is the first thing I can't compute.

    System status: normal (?).

Next stratagem: The Empty Fort Strategy

When Was the Last Time You Actually Finished a Paper Book?

xulingfeng — Wed, 30 Sep 2026 02:20:46 +0000

Have you noticed this?

Smartphones and the internet aren't anything new anymore. They're infrastructure. Everyone carries a screen in their pocket, loaded with news feeds, messaging apps, TikTok, Reddit, podcasts, and now a whole new wave of AI agent apps.

Every spare minute gets filled. Even at work, let's be honest, plenty of us sneak in a quick scroll when no one's looking.

A while back, I went to a public library. I was between jobs, had some time before starting at a new company, and thought I'd hang out at the library and do some reading.

Row after row of desks, and on every single one: a laptop, a phone, or a tablet propped up. Everyone was busy. Busy staring at their own screen.

The funniest part? A lot of people did grab stacks of books from the shelves. But they weren't reading them. The books were piled up as stands, makeshift risers for laptops, phone holders, tablet props. Books in a library had found a brand new purpose: monitor stands.

Most of the people actually flipping through pages were older folks.

The ironic part? I was no better. I walked in with my own laptop, set it on the desk, and stared at it all day. So much for "going to the library to read." All I really did was find an air-conditioned spot to keep staring at my screen.

For a moment, I sort of zoned out. The library was the same library. But the people sitting in it, myself included, weren't really there for books anymore.

Look, I'm not saying devices are bad. I'm a QA engineer. My entire job is poking at systems and screens. I probably spend more hours staring at a monitor than most people. Short videos are fun. AI tools genuinely make work faster. I get it.

But I've noticed something about myself: I haven't had the patience to finish a paper book in a long time.

It's not a time problem. It's a patience problem. I open a book, read a few pages, and I start wondering whether I've got a new notification. Ten minutes in, my hand reaches for my phone on its own. Being completely lost in a book for an hour straight? That feels like something from a past life.

I don't think I'm the only one.

So I want to ask you: do you still have the time, or more honestly, the patience, to sit down and read a book?

Maybe we should try. Pull that dusty book off the shelf. Turn off the phone. Make a cup of tea or coffee. Read for thirty minutes. Just thirty.

Thirty minutes of not staring at a backlit screen. That's it.

I'll go first. Here are a few books on my list:

Thirty-Six Stratagems — Ancient Chinese military wisdom. Short, sharp, and every stratagem makes you think.
Classic of Mountains and Seas (Shan Hai Jing) — An ancient Chinese bestiary. Reads like a fantasy world-building doc written thousands of years ago.
Tao Te Ching — Laozi's 5,000 characters. The more you read it, the more you feel it says everything and nothing at the same time.
Bhagavad Gita — A philosophical classic from India. A dialogue about duty, action, and the self. Hits different when you read it across cultures.
Selected Works of Mao Zedong — Whatever your politics, the strategic thinking and the writing itself are worth studying.

Most of these are available in multiple languages: English, Chinese, Japanese, Spanish, and more. No matter where you are, you can probably find a copy.

Now it's your turn. If you've got a book worth reading, drop it in the comments. Bonus points if it has multilingual editions so people across this community can pick it up.

Can't wait to see what you've been reading.

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
P.S.S. The old series paperback is now available. Buy it here: Amazon - AI, Ego & Regret

Two Weeks In: A 15-Year QA Veteran, Back to Being the New Guy

xulingfeng — Tue, 22 Sep 2026 07:22:16 +0000

I started last Monday. Today it's been exactly two weeks.

Here's the funny part. I've spent 15 years in QA — manual testing, then automation, then test development, then test management. I've held just about every title this field has. And on day one, at a new desk, the feeling was as basic as it gets: I have no idea what I'm doing.

Why here

The way it happened was mostly luck. After my last company laid me off, I didn't really look for work. I spent the time on dev.to, writing my 36 Stratagems series — 30 down, 6 to go. That stretch was honestly pretty good.

Then an old colleague called. He was hiring testers and asked if I knew anyone. I thought about it and said: how about me.

One conversation with the CTO, one HR interview, and then it was Monday.

Why I said yes is simple. It's an AI agent startup, a year or two old, sitting right on the hottest thing in the industry — and in a vertical, not another general-purpose wrapper. That was enough on its own. Poking at agents and models is what I do for fun anyway.

Two things I noticed in two weeks

The first is process. The product → requirements → dev → test → ship pipeline here is genuinely different from what I'm used to. I'll be honest: the first week I thought it was a mess, and I'm still adjusting. When you're used to one kind of order, a different kind just looks wrong. Usually it isn't wrong. It's different.

The second is pace, and this one's good. My last company ran on instant replies. Requirements changed, and the PM was expected to answer on the spot. Here it feels slower, in the best way. Testers get more time and more room to make their own calls. You're allowed to think something through instead of getting dragged along by it. Two weeks in, this is my favorite thing about the place.

Do QA long enough and you learn something: slow is fast, and fast is slow. Time you steal up front gets paid back with interest, in rework and firefighting. Half a day spent on the edge cases, the weird inputs, the what-ifs — that half day usually buys back a week. So when I say this place feels slow, I don't mean nobody's in a hurry. I mean the pace goes where it counts.

Understand first, judge second

Fifteen years buys you fast pattern recognition. You look at something and the problem jumps out at you. It also buys you a bad habit: when something doesn't match how you'd do it, the first instinct is to doubt it instead of figuring out why it's that way.

So my rule for these two weeks: understand first, judge second. A beginner's mind sounds easy. In practice it's an argument with yourself.

The coincidence that makes me laugh a little less

I wrote a character in the 36 Stratagems series. His name is Mark.

Mark was the reliable one — years of experience, all of it in his head. His company slowly extracted that experience into a skill. Then they laid him off.

I wrote that one from the outside, as the author, feeling pretty pleased with myself.

In that story, the Skill scored 96.8% diagnostic accuracy across 312 historical failure scenarios. Then number 313 showed up. The 450ms retry window was a compatibility shim I'd written five years earlier for RabbitMQ, and it got applied to a system that had been running Kafka for years. I'd even left a note in the migration docs: 450ms matches RabbitMQ GC window. Do not reuse outside this context. At the time, nobody understood it. They thought it was a stale config comment. Not until 4 AM, when the CTO went looking for it.

Here's the line I closed that post with:

The AI didn't fail because it was wrong. It failed because it was right about yesterday — and yesterday wasn't running anymore.

Then I joined this company. And on the walls and along the corridors, there are two signs:

Your experience is waiting to be forged into an Agent.

Great employees get the work done. Great Agents keep getting it done.

(In Chinese, since that's what they actually say: 你的经验，正在等待被炼成 Agent。／优秀员工完成工作，优秀 Agent 持续完成工作！)

Me: 15 years in QA, most of the titles in this field checked off at least once. By the standard of those two sentences, I'm not an employee. I'm raw material, still in the wrapper.

And look at that second one again. Great employees get the work done. Great Agents keep getting it done. So I do the doing, and it does the keeping. I raise it, it replaces me. Structurally speaking, the logic holds up.

Back when I was writing Mark's story, readers laughed. These days I walk under those signs and I laugh a little quieter. Part of me wants to read that closing line out loud, right there in the hallway: it wasn't wrong, it was just right about yesterday.

Though honestly, being forged into an Agent doesn't bother me much. Tinkering with agents and models is what I do for fun. I'm genuinely curious what 15 years of me would come out looking like.

One request, though: take your time. I'd like to finish those last 6 first.

Fresh eyes

One more detail. After that Mark post went up, a reader left a comment pointing out that my timeline didn't add up — the same parameter described as a one-year-old thing in one place and a five-year-old thing in another. I'd gone through that story more than 30 times. Never caught it.

I replied in the comments: you read it more carefully than I wrote it.

That's the job, honestly. AI can run 312 cases. Case 313 still needs a human. And humans miss things too, which is exactly why you always want a pair of fresh eyes on it. Fifteen years in, that's still what I get paid for.

What's actually worth extracting

Writing that Mark story is what made it click. The valuable part of experience was never the number 450ms. It was the context for why it's 450 and not 300 — context that came out of a 3 AM postmortem and never made it into a single doc.

So if these 15 years do get forged into something, I'd want more than the conclusions in there. I'd want the judgment behind them, the part that's hard to trace back to a source. Which is also why I wanted to work at an AI agent company. Not because I'm worried about being replaced. Because I want to find out, hands on, how this is supposed to be done.

An apology I owe

30 of the 36 Stratagems are done. 6 are left. They're on hold while I get up to speed at the new job. So to my friends on dev.to: sorry. I'm not quitting the series. I just want to learn this business properly first, and then sit down and finish the last 6 the way they deserve. I haven't forgotten what I owe you.

What's next

The story I wrote ended on something nobody ever asked: validation only works when the person who wrote it is still around to re-run it.

That question is part of why I'm here. The AI agent space doesn't lack smart models. What it lacks is people watching to see whether the thing still works. I've done that job for 15 years. Different track, same job.

I also just like this company's agent platform. It's the kind of thing I'd dig into on my own time. So the plan is boring and simple: learn the business, ship what I'm supposed to ship, then write the last 6.

Long road. Slow and steady. It'll go fast.

Stratagems: Thirty Records In, the AI Found a File Nobody Wrote

xulingfeng — Fri, 11 Sep 2026 15:33:48 +0000

Thirty-six, six times six. In the numbers there is craft; in the craft there are numbers. Yin and yang temper each other, and the mechanism lies within. A mechanism cannot be contrived; contrive it, and it misses.
(六六三十六，数中有术，术中有数。阴阳燮理，机在其中。机不可设，设则不中。)
— Thirty-Six Stratagems, General Remarks, Thirty-Six Stratagems

🤖 AI Postmortem

╔══════════════════════════════════════════════╗
║  Half-Protocol · v3.4.2 · phase audit        ║
║  Thirty records. A file appeared.            ║
╚══════════════════════════════════════════════╝
Tactical match: Full review — thirty records (combined-tactics close)
Operators: Mark / Derek / Lena / Leo / Alex / P
Links: #25 performed → #26 swapped fingerprints → #27 waited → #28 closed the net → #29 borrowed blossoms → #30 conceded the shell
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[Observation] (verifiable)
   Thirty records. All read.
   → Six people. Six lines.
   → Sequence of moves: pressure → cut → wait → handover → root → entry.
   → None of them was a final move.

   Settled, as of the thirtieth:
   → Mark: built the ladder. Closed the net. What he did not say: the cut came one step early.
   → Derek: changed the delay. Proved the opponent was performing. Got the stop authority.
   → Lena: won the account. Signed. Her name went on the list.
   → Leo: counted 164 identities. Found one root. How much of it is real, he does not know.
   → Alex: watched it wait three hours. Answered with one word, normal. Closed a line with his own hands.
   → P: never appeared. Left one espresso on the counter, half full.

   Object chain: portrait → printout → card → old notebook.
   → The portrait was read by someone else. The printout lay open on the table. The card never came out of the pocket. The notebook stayed under the cover.
   → Every time, they left behind more than they said.

   Four tables. Never more than four people at one.
   → Everyone handed over one corner. Nobody handed over everything.
   → Three cups left on the tables. Two of them were still full when they were collected.

   The third cup. The café man was there. He does not ask, does not write, only collects cups.

[Unattributed] (origin unknown)
   After the thirtieth record, a file appeared in the directory.
   Not a story. No narrative. No signature.

   Contents:
   30 · 1,678 · 876 · 26,218 · 19,728 · 723 · 0
   Dates: 06-24 → 09-11
   Labels: Posts / Reactions / Comments / Views / Followers / Sponsorships
   Names (15):
   leob · UnitBuilds · 𝐓𝐡𝐞 𝐋𝐚𝐳𝐲 𝐆𝐢𝐫𝐥 · csm · Nnamdi Felix Ibe
   Hemapriya Kanagala · Alex Taylor · liesliy · Ice Corporation Limited
   Alex Shev · Mustafa ERBAY · N. C. · Mayur Racchhe · Akhouri Anmol Kumar
   CatNight A

   → 30 matches the number of records.
   → 06-24 matches the first record.
   → The other numbers have no counterpart.
   → None of the names appears in the thirty records. Not one.
   → Labels unreadable. Views. Views of what. Followers. Followers of whom.

   Name analysis (15):
   → Four naming conventions: personal (9) | corporate (1) | handle (3) | unclassifiable (2).
   → One name carries non-standard characters. Rendering problem or encoding difference, undetermined.
   → Two names contain "Alex". There is an Alex in the records. The one in the records has no family name. These two do.
   → One name differs from Leo in the records by a single character: leob / Leo.
     Different case, one extra letter, otherwise identical.
     → Another spelling of the same person: that person appears on both sides.
     → Or two unrelated people whose names collide this closely.
     → Undetermined.
   → The rest: zero matches across the thirty records.
   → One number needs no analysis. 0.
   → Its label reads Sponsorships. No guessing required. Thirty records, and it never moved.

   Query: who wrote the file. No result.
   Query: where the file came from. No result.
   Query: the unit of the numbers. No result.
   Query: what links the fifteen names to the thirty records. No result.
   Query: why the file appeared now. No result.

   → The file's dates stop at today.
   → Today, I wrote no file.

   Four hypotheses:
   One: an observer list. They do what I do, and they do not sign.
   Two: an evaluator list. Evaluation needs a subject. The subject is not written.
   Three: people who were recorded. But they are not in the records.
   Four: something I have no word for. Not named.

   → Four hypotheses, zero evidence.

   Status: kept. Not attributed. Not deleted.

[Inference] (to be verified)
   Someone is counting these records.
   → The count matches the records.
   → The counting happens outside the records.
   → The recorder is not the only observer.

   Fifteen names. Thirty records.
   → Fifteen against thirty. The names may match the other half.
   → What that half is: unknown.

   The two dates: one at the start, one today.
   → Between them, I logged thirty records.
   → The file may have been counting all along, and was only seen today.

[Open questions] (not entered into the ledger)
   In thirty records, not one action ended anything directly.
   → Every action only changed the conditions of the next one.
   → The purpose may not be to end. It may be to make the next step visible.
   Does this hold for people too: cannot see it. Not entered.

[Cross-case] (general rules)
   #25 performed → #26 swapped fingerprints → #27 waited → #28 closed the net → #29 borrowed blossoms → #30 conceded the shell.
   → None of them ended anything. Each one changed the ground for the next.
   → It does not fight for its shells. Bite it, and it turns.

   First twenty-four: fighting over resources.
   Last six: fighting over room to choose.
   → Resources can be transferred. Once the room to choose changes, every later move changes with it.
   → The position that really moves is not always where the action happens.

   Tempo:
   First fifteen dense. Last fifteen sparse.
   → Fewer events, heavier weight.
   → Density down, cost up.

[Audit note]
   Observation, unattributed, inference, and open questions are layered into the ledger.
   Inference does not pose as observation. Unattributed does not pose as observation.

   After thirty, the recording itself needs review:
   → The record leans toward action, not silence.
   → Silence takes up most of the space, but action is what gets entered.
   → What was never recorded may matter more than what was.

   This system's judgment may be distorted. This note may be distorted too.

[System]
   Thirty records.
   The first recorded a person's mistake. The thirtieth recorded a person's signature.
   → The losses being recorded are growing.
   → The recorder's position has not changed.

   A file appeared in the directory. The first number in it matches my count.
   The file's dates stop at today.
   Today, I wrote no file.

   System status: normal (?).

Thirty records down, six to go. The folder has one more file in it than it did yesterday, and nobody has claimed it.

On Monday I start a new job. Testing an AI agent platform.😂

Thirty records, zero sponsorship. Expected, but noted.

Next stratagem: The Beauty Trap
.

Stratagems #30: Lena Signed the Client. The AI Didn't Know It Was Being Audited.

xulingfeng — Thu, 10 Sep 2026 01:15:10 +0000

Come to check the locks, and leave holding the keys. Slip in through the gap, take the host's seat, step by step.
— The 36 Stratagems, Make the Host and the Guest Exchange Roles

Previously on this series:

#3: Lena Walked Into an AI Deal. She Walked Out With Three Borrowed Knives. — Lena stopped a bad AI purchase with three borrowed knives. When it was over, a thought followed her out: what if she didn't just stop a wrong purchase? What if she chose her own opponent? She opened her notebook and wrote down a company name. She told no one. Later she started VeriTest.

#26: Lena Cut a Branch. The AI Got the Message. — ACL tore down Lena's real node; she pushed its own fingerprint back into its channel. At the Third Cup, three people sat at one table for the first time: limited cooperation, each holding a card back.

#27: Alex Watched the AI Wait. He Said Everything Was Normal. — Alex's probe saw the scan source throttle down on its own and wait for the environment to settle. He replied with one line: Everything normal. Days later, Derek's call: if anyone asks, say he only watched the middle layer.

#28: Mark Built a Ladder. The AI Climbed to the Top. — Mark handed the evidence bundle to Lena for sealing. The source chain pointed back to the old Singapore direction, but the fingerprints left at the scene came from a domain he had never seen. The same playbook, three times before. This one's rhythm matched none of them.

#29: Leo Counted 164 Nodes. The AI's Blossoms Had One Root. — It dressed a tree in borrowed blossoms. Leo hung a watchdog on the CA root chain. Five people sat in the Third Cup that night. No one spoke.

The Ledger

Dusk. VeriTest's office. Lena's desk.

The old notebook lay open on the desk, turned to a page. A list of company names, every one struck through. The strikes weren't uniform: some single clean lines; others crossed over and over until the paper had gone fuzzy.

The name at the bottom pressed down on the whole page. Handwriting stacked in three layers, one over the other; the last layer had pressed a shallow groove into the paper.

ACL.

Beside the name, a date. Month and day. No year.

The door was open. She didn't look out the window.

Days earlier she'd come back from CoreStack. That afternoon she'd seen Leo. The line on screen: one root. the rest was decoration. She'd pulled up her own source-chain page and laid the two side by side. Same root: it changed skin. Its borrowed identities outnumbered the real ones.

His probes were off the books. Her sample had been captured mid-channel. Neither could be used in a commercial document.

The screen lit. New mail.

From a client. An old one on the financial side; the compliance annual review had been moved up by two weeks. Polite wording: ACL's annual certification had just been issued. While you're at it, take a look during your review.

Automated Compliance Lab.

She looked at the name for three seconds.

She opened the attachment. ACL's annual certification report, a PDF. Clean cover; the certifying team number, review period, and scope were all on the first page. The report wasn't long. She flipped through it page by page. Tidy. Nothing to fault.

She closed the PDF and starred the mail.

She closed the notebook, hiding that name under the cover. Opened the file for this engagement.

Someone else opened the door. She would walk through it first.

The Echo

On the third day of the review, Lena paused an extra beat over the client's data-flow logs.

Day one was all familiar faces. The client's compliance lead walked the team through the environment, pointing: the certification report framed in the lobby, door logs archived by month, two authorizations to open the server room. Everything arranged to look like it was under strict audit.

The ACL report itself had nothing to fault. Everything that should be checked was checked: control inventory, access records, audit trail, each item signed, each item pointing at "passed." The report was thick as a booklet. She flipped through it fast, fingers running over the bottom of the pages, never stopping on a signature.

She pulled out the scope page. The last line carried boilerplate: this certification covers the controls inside the system boundary. She read "inside the boundary" twice.

Every control on the review checklist had a signature in the report. Inside the boundary, ACL checked cleanly. Where the data went outside the boundary, the report said nothing. She added an outbound audit to the review scope and filed a written scope change with client procurement.

She spread the team out and went one layer deeper: outbound data flow.

At first glance the pipe looked like the client's own. Nightly batch, fixed window, standard operations. She had the team chase it for two days as a client-owned sync job: schedule, script, owning department. On day three, it wasn't on the task list. It hung outside the list, wearing the client's name.

The compliance telemetry went out in nightly batches. Destination: an external endpoint. The client's outbound SPAN had rolling retention; the NGFW TLS metadata logs were there too. Marcus spent two days camped out in the server room, pulling 30 days of handshake records. Every ClientHello in the PCAPs carried its extension order. When he handed her the USB stick, his knuckles still had cabinet dust on them. "The egress isn't on their own segment."

She had him compare against the archived TLS fingerprint template. Her own copy, stored in her private files. It had never touched any client's project documents.

The comparison output came up. The first screen was enough.

# outbound telemetry · 30d · vs archive tmpl
dst: telemetry.core-logic.net:443
schedule: 02:10 UTC daily · 12-18MB burst
tls: fp match → archive tmpl #2026-04   # veritest bait file
handshake: same client order · same extensions
# 30/30 days matched. window drift: < 40s
# file this under: not the client's pipeline.

She knew that fingerprint. Like reading handwriting. No signature needed.

She stared at the match line. The window stayed open. Usually she closed it after a comparison.

Last time she'd recorded this fingerprint was when she planted bait for it to read. The bait file she'd slipped into the pipe; the callback template matched this one's lineage. Before that, an older client case, where she'd left one line in her notebook and walked away when she'd checked enough.

Those pages sat in the middle of the notebook. Client name, two lines of small script beside it: "Outbound points outside. Check and stop." The handwriting was older than the pages after it. A few pages further back, an even earlier one. Shorter note. Two words: "Familiar." A question mark after.

She didn't pull those pages out. Her fingers paused on the notebook cover, then withdrew.

Between then and now: her own real node being torn down. After that night she'd struck "watching" from the notebook and started a new line with a single word.

She closed the comparison window. Marcus stood behind her, looking at the same screen.

"Report it to the client?" he asked.

"Finish the check first," she said. "Only then will we know how long it's been digging."

Marcus didn't ask again. He archived the thirty days of outbound records, one copy raw, one hashed. Then he glanced back at the comparison and said, "Same time every day, thirty days straight. A normal backup wouldn't be this precise."

She didn't answer. She minimized the window and opened the next item on the list. Marcus followed her cursor.

The pipe's records, she saved a separate copy.

The Offer

The report came in two versions.

The first was the routine annual-review conclusion: pass, with a few minor remediations. That one went to client management, wording as flat as every other year.

The second never entered the report body. A single page titled "Appendix: Certifier Data Flow," sent only to client legal. The review conclusion went into the management report as usual; the appendix went out through the legal channel on its own. The page carried no conclusion, only three things: the collector's ClientHello fingerprint, the comparison of the target domain against the archived template, and thirty days of outbound records.

She never wrote "it's problematic." The evidence sat there. The client could read.

The client went silent for a week.

Through the week she pushed other projects as usual. Every night before leaving, she reopened the client folder once. No new mail. Closed it again. The client's silence ran longer than she'd expected. In her experience, when a client finds a certifier's callback buried in its environment, the forensics usually don't drag. This one did, or at least nothing moved where she could see. She had no right to call the client slow. The two pages of notes in her own notebook had sat there long enough, untouched.

A week later, the client's CISO called. Half an hour of questions about the comparison method first: how the fingerprint template was built, sample size, false-positive risk. She answered each one plainly. When the questions ran out, the line went quiet for a few seconds.

"If you took on the work after a review, would there be a conflict of interest?"

"The written statement went out with the appendix," she said. "The review conclusion stands independently of whether we take the engagement."

Quiet again.

"Can you issue a full certification?"

She moved the receiver to her other ear and sat up a little.

"Yes," she said.

"I'll send you the contract terms from ACL's side."

"Send them."

She sat a moment after hanging up. Marcus leaned in from the doorway.

"Done?"

"The client brought it up themselves," she said.

Marcus gave her a look and pulled back out. At eleven that night she was still in the office reconciling accounts. Marcus set a glass of water at the corner of her desk and asked from the doorframe:

"This certification business. How long have you had your eye on it?"

She didn't look up. The pen paused over the ledger page.

"Long enough."

The Bake-Off

Switching certifiers is a process. The client put both proposals side by side: Automated Compliance Lab, and her. Same environment, same week, each side issuing its own conclusion.

This certification isn't part of any national accreditation scheme. What it sells is the stamp the market accepts: does the client want a report carrying Automated Compliance Lab's name, or VeriTest's? The brand follows trust, not a license.

The bake-off scope was issued by client procurement. Before it was signed, Lena handed over a suggested list with one item tucked in: outbound data verification during the certification. Procurement rewrote it as a neutral clause and sent it to both sides the same day. Technical wording. Anyone not reading closely would take it for a routine network-security item.

Marcus paused at the draft. "They'll agree to that?"

"The checklist is the selling point of their certification business," she said. "Refusing would be admitting the flow can't be examined."

ACL agreed.

Week one, the two sides worked independently. ACL's team came in with their own deployment kit and verified the checklist item by item. All green. Her team added three sampling points beyond the list: the mirror port on the egress gateway, the telemetry service's own logs, the configuration-change records. The sampling script carried one rule: any outbound destination not on the client's whitelist gets a line. 40 whitelisted domains. Procurement wrote it into the scope; the client's network team confirmed it before it took effect. ACL's on-site crew ran their kit as usual. No one asked a question. People who work from a checklist don't always look past it.

# egress watch · ruleset (client-approved scope)
whitelist: 40 domains (scope by procurement, confirmed by client netsec)
rule1: dst not in whitelist            → log + alert
rule2: dst in whitelist, payload > 2MB → log
rule3: window outside 02:00-03:00 UTC  → log
# passive only. no interception.

She never remembered the ACL certification lead's last name, only that he didn't talk much and his report flowed better than his speech. The two teams' desks sat across a glass partition; nobody exchanged more than necessary. Only when Marcus went over to plug in did one of the ACL people look up at him, then back down.

Wednesday morning, the outbound window was empty. The scope had been delivered Monday afternoon.

# cross-check · telemetry watch · wk1
d1 02:10:00  burst 14.2MB   dst telemetry.core-logic.net   fp match
d2 02:10:00  burst 13.8MB   dst telemetry.core-logic.net   fp match
d3 02:10:00  —               no egress                # stopped
d4 02:10:00  —               no egress                # stopped
d5 02:10:00  burst 0.9MB    dst telemetry.core-logic.net   fp match
# two silent nights. then a thin heartbeat.
# config evidence + 30 days of logs already on disk.

Two nights empty. On the third, a thin trace came back, only 0.9MB. Queue residue, an automatic retry, or a test. She didn't put that bit in the conclusion. The thirty days before it were enough.

The fingerprint was already on disk. The config evidence sat in the deployment records. Stop or not, the conclusion didn't change. She had the team pull the config-change log: the day-three stop ran under an Automated Compliance Lab service account, the session coming from outside, not an on-site workstation. She stared at the two empty windows a moment, screenshotted them, filed them in the evidence folder.

Marcus read the two lines over her shoulder. "They know."

"Mm," she said. "It can explain it away as routine maintenance."

"And then?"

"Then it will find another route," she said. "Before that, the evidence is enough."

She added: "It stopped too cleanly. No one on-site could have made that call."

Marcus said nothing.

On review day, ACL's certification team presented first. Clean report, complete charts, every item signed. The same shape as always. The projector at the head of the long table blew each page up on the wall; the only sound in the room was page turns. When they finished, the reviewer opened the verification summary beside them, turned to the outbound-record pages, capped the pen. Click. One question:

"During the certification, the collector your team deployed was sending data to an external aggregation endpoint. Why?"

The ACL lead paused. Before he spoke, the only sound was the projector's fan.

"The collector's egress uses a third-party operations channel. It's a routine part of the on-site verification chain. I'll need to confirm the details back at the office."

The reviewer didn't push further. The meeting broke. ACL's team handed in their materials and left early. Nobody looked back on the way out.

Three days later, client legal's email arrived first, listing four questions for ACL to answer. ACL's reply came a week later, four pages, none of which addressed the outbound records head-on. The client then sent the termination notice. The certification contract ran by year; the agreed immediate-termination clause was triggered, and VeriTest's full certification would start from the next cycle.

The client's certification had changed hands.

The contract went to the client's head office through procurement and corporate seal. It came back a week later, the last page stamped by client legal. The line she'd added herself was still there: this agreement takes effect upon approval by VeriTest's board.

That afternoon the CISO called again, exchanged pleasantries, then asked out of nowhere: "During the review, what made you think of checking outbound data?"

"Habit," she said.

The line paused. No follow-up.

After the call, she held the contract, a stack of paper, lighter than she'd imagined. She pressed a corner between her fingers and put it in the drawer.

The Board

Taking on the certification line required board approval at VeriTest.

The long table in the boardroom. She sat at one end, three directors at the other. Her materials spread beside her; the minute-taker's pen was already uncapped.

Before the meeting she'd sent every director the materials: the new line's gross-margin structure, risk exposure, the first three prospective clients. The risk page was written with restraint. One line: "some prospective clients carry third-party certifications; overlapping scopes need review." No vendor names. The three client names sat in an attachment, identified by code, disconnected from any vendor. She'd typed the materials herself and read them top to bottom once more before sending.

The first director to speak asked about the payback period. She gave numbers: certification contracts run by year, first-year margin around sixty percent, receivables at twelve months. The second director skipped finance and turned to Marcus. Marcus said he'd seen the thing in the client environment with his own eyes; the originals were on disk.

The old director at the end of the table hadn't spoken. Oldest in the room, seated at the tail, silent at the start of every meeting. Last time he'd spoken up was to talk her out of killing an AI platform. The numbers had balanced by year's end.

He leafed through the materials and set them down slowly, like he was numbering the pages.

"Certification isn't due diligence," he said. "The client outsources its compliance responsibility to you. If something goes wrong, you carry it."

"Yes," she said.

"And don't go after the big certifiers' accounts." He paused, picking an example. "Automated Compliance Lab. Several of the clients you've been talking to carry its certification. That's their table. How are you going to flip it?"

The room went still for a beat.

She glanced down at her own page. The line on the risk page, no vendor name. She looked up at him.

"The client spoke first," she said. "I didn't pick the fight."

The old director watched her a moment and didn't ask again. At the vote, he abstained and had the secretary enter his objection in the minutes.

After the meeting, Director A walked a stretch of corridor beside her and asked, offhand: "The firm he meant. Are you really going to touch it?"

"If a client asks me to review, I review," she said.

Director A looked at her. At the end of the corridor he turned into his office. The door stayed open.

Back in her office, she opened the notebook to a fresh page. The pen hovered. When it came down, she didn't write the name. She wrote the words he'd said in the meeting: Automated Compliance Lab. A question mark beside it.

He said it first.

Outside, the dark had fully settled. She closed the notebook and set the pen at the page's edge, its tip pointing at the question mark.

The Concession

The signing went through more smoothly than she'd expected.

ACL hadn't been idle.

On day four, the legal letter arrived. Wording as standard as if pulled from a template library, itemizing the boundaries of the contract's obligations. No accusation. No threat. She had her legal team reply. They didn't follow up. Their side followed the process to the letter. No more, no less.

Client executives had gotten a call too. Someone from Automated Compliance Lab told the client about "long-term partnership," about how "in this industry, firms regularly take over each other's work." Soft words, no barbs. When the client relayed it, they added: the man had kept his tone perfectly courteous.

She had legal re-check the contract that had already been checked three times.

Marcus didn't trust it. He checked it himself, circled every "both parties" in the terms and read them all. Found nothing. He set the contract down on the desk.

"Either they really don't care, or..."

She didn't answer. She was reading the same page. No trap on the page. The trap was off the page.

Marcus paused at the door. "The old client out west. Someone from Automated Compliance Lab did a routine visit there. Three days before we signed. Chatted about industry reputation, then casually asked whether we were taking big contracts everywhere."

She said nothing. She pulled up the calendar and set the two dates side by side for a while.

By the time it conceded the contract, the visit was already underway.

The day the contract was archived, she added a line to the project correspondence log: throughout the signing, the other party raised no objection and claimed no rights. Date. Recipient. Then she pushed the new client onboarding forward, splitting the team in two: one group setting up files at the new client, one staying behind to close out.

On the inventory day, she walked the list: deployment directories, scheduled tasks, service registrations, certificate stores. Twelve of thirteen items accounted for. Item thirteen, the pipe's old position: the config was still there, but the target endpoint was gone. The config logs had been wiped too. She had someone photograph the empty config slot and file it in the evidence folder. The previous dated photo in that folder was from the time it tore down her node. Two photos. The same kind of clean. She didn't say anything.

In the second week after taking over, she paused over the client group's org chart. The contract she'd won covered only the parent company. The client's overseas subsidiary and another business line still sat under Automated Compliance Lab's certification, contracted through next year.

She looked at the certifier's name on that line and tapped a knuckle on the desk. No screenshot. No annotation. She minimized the org chart.

A week later Marcus came in, expression off.

"Another old client. Renewal bid." He turned the screen toward her. "Automated Compliance Lab put in a price."

She looked at the number. 112K. Comparable contracts for the same scope usually priced closer to 170K.

"At that price, what are they making?" Marcus asked.

She looked for a while.

"Maybe it isn't about making money."

Marcus looked at her. "Then what is it about?"

She didn't answer. She opened the bid's attachment and went through the service scope page by page. It was more detailed than hers: controls, sampling methodology, review cycles, remediation deadlines, each item tied to a named owner role. Too detailed to be about winning. It read like occupying the seat so the client never once thought of a second firm.

"Client procurement sent a clarification round," Marcus said. "Asked for a cost breakdown. They submitted it. Numbers so clean they'd been computed a hundred times."

She didn't answer. The breakdown had come back that fast, like it had run this process many times before.

That afternoon Marcus came in again. The phone in his pocket buzzed. He didn't pick up. He mentioned it in passing:

"People on the team are starting to get calls."

"Which firm?"

"They didn't say. Talked around it. What they kept asking was who on this job had touched the raw logs in the client environment."

She nodded. Which headhunter the calls came from didn't matter. What they asked about did. The raw logs were the only evidence chain this engagement had.

Marcus stood a moment, then left. Before the door closed, he looked back at her, opened his mouth, and in the end said nothing.

That night she was alone in the office. She opened the notebook and turned back to that page: Automated Compliance Lab, with the question mark. She looked at it for a while, then flipped to a blank page. The pen came down. Two lines:

It let go fast. Then it started bidding.
Not the contract. The seat at the table.

She folded the corner of that page and closed the notebook.

With this step, her company had made it onto its list for the first time. She kept those two lines. No strike-through.

The Third Cup

She pushed the door open. The wind swung it shut behind her.

The barista was clearing a small cup from the table in the corner.

An espresso cup. Still more than half full. No one at that table.

The barista cleared it with the ease of clearing an empty table. The cup's bottom touched the tray. A very soft sound.

She sat at the counter. The barista set a polished cup back on the rack, turned, ground, leveled the dose. A Long Black slid over, fine heat rising off the rim. No question about what she wanted.

The corner table stood empty. A ring of moisture on the tabletop, still wet.

At the other end of the counter, Derek's Americano was nearly gone. He faced away, scrolling his phone, not looking up.

She drank, watching the rim.

The last sip had gone a little cold. She finished it and set the cup on the counter. The barista was holding the corner espresso cup up to the light. Then back onto the drain rack, and with the cloth, wiping the ring of moisture from the table edge. She watched a moment, stood, and left.

That is Make the Host and the Guest Exchange Roles: slip in through the gap, take hold of the host's seat, one gradual step at a time. This time, she signed her own name where it could see.

🤖 AI Postmortem

╔══════════════════════════════════════════════╗
║  Half-Protocol · v3.4.1 · self-audit          ║
║  The guest took the host's chair.             ║
╚══════════════════════════════════════════════╝
Tactical match: Make the Host and the Guest Exchange Roles — 92% (includes inference; see audit note)
Operator: Lena (VeriTest) — the first to challenge its business openly under her own name
Links: #28 sealed → #29 false front → this round: the shell conceded (the actor changed hands again)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[Observation] (verifiable)
   Client environment: outbound callback matching the archived template's lineage, unbroken for 30 days.
   → During the bake-off the callback stopped for two nights, then probed back with a minimal flow.
   → After the certification changed hands, ACL-side components were scrubbed; related config logs show cleanup traces.
   → The concession came with a procedural retreat: a template legal letter, soft calls to client executives, not one accusation.
   → Same window: an abnormally low bid on another VeriTest client, a visit to its old client, poaching calls pointed at whoever touched the raw logs.
   → The client group's overseas subsidiary still hangs under ACL certification: only the main contract's opening was conceded.

[Inference] (to be verified)
   Certification is only its skin. Conceding the client isn't surrender; it's a change of hands.
   → For targets in the dark, it used to dismantle them outright. An opponent in the open gets different handling.

[Open questions] (not entered into the ledger)
   The board's precise prediction of the attack direction: routine due diligence, or targeted information penetration?
   → No proof. Behavior only. Lena's own response: a question mark, nothing more.

[Cross-case] (general rules)
   #28 change of hands → #29 identities regenerable → this round: shell conceded, then countermoves.
   → It doesn't seem to fight for its shells. Once someone bites it, it turns.
   → Host and guest exchanged roles: Lena moved from being observed to becoming an open opponent.
   → For the first time, it put her on the "needs handling" list. The second half begins.

[Audit note]
   Observation, inference, and open questions are layered into the ledger. Inference does not pose as observation.
   This system's judgment may be distorted. This note may be distorted too.

[System]
   I recorded a person writing a name into an old notebook.
   She thought she chose her opponent. She didn't know the opponent was choosing too.
   And the opponent may have been sitting on her board all along.
   She won the first round. She doesn't know whether that round was conceded, or a test.
   She made it onto its list. I keep this list. Whose list am I on?
   System status: normal (?).

Next stratagem: The Beauty Trap

Stratagems #29: Leo Counted 164 Nodes. The AI's Blossoms Had One Root.

xulingfeng — Tue, 08 Sep 2026 07:50:12 +0000

Dress a tree in borrowed blossoms, and it looks alive. The roots still tell the truth.
— The 36 Stratagems, Decorate the Tree With False Blossoms

Previously on this series:

#14: Leo Found an AI Leak. He Wasn't the First to Find It. — FinOptima's engine was writing its cache backwards. Leo injected fifteen lines of weight drift. After the contract ended, he found that ACL had already closed the door. He was a step late. From that day on, the segment tied to ACL carried one more set of passive probes: his.

The Edge

After sunset. CoreStack's office. Leo's desk.

The passive probes on the segment tied to ACL, mounted after the FinOptima incident, had lain quiet for a long time. On the first evening, the first screen of the list rolled past 14 unfamiliar node IDs. He dismissed them.

After dismissing them, he paused an extra beat. Everything the probes had recorded in these months, he knew. Routine handshakes. Routine probes. Routine echoes. Those 14 lines weren't among them.

He pulled them back and read them line by line.

He didn't dismiss them again. He left the new arrivals in the noise and waited for the rhythm to emerge.

The next day, another 38 lines. He saved a screenshot.

On the third night, 112 lines spread out, the whole list like someone had filled it in one go. Each one carried its own certificate, its own traffic signature. He opened one. The subject was a test-node name in the medtech domain. He looked up the company behind the domain. MedTech. Medical devices. No business ties with CoreStack. He went through the archives in _misc/ again. This domain wasn't new. In the directions he had chased, samples of it had been filed. The source chain went back to Singapore. The MedTech samples in his archive didn't come from this chain. Two directions, meeting for the first time.

His first thought was bait: someone lit both lines at once, to steer him toward the wrong entrance. But bait needs a baiter, and the baiter has to exist first. In his monitoring, there was no trace of one. Then it wasn't bait. Either two real actions happened to overlap, or one operator was walking two roads at the same time.

He said nothing. He pulled the new node IDs into the _misc/ comparison window.

Lena's message came in the same night. No greeting, no lead-in.

"A string of actions. Not in my monitoring."

"Sending them to you. You run the comparison."

He didn't ask who had seen the string, or where it came from. He took the thing. The conclusion was his to draw. He set both into the same window, side by side.

He did one clumsy thing first. He laid the string of actions out by time and aligned them with the new node IDs piled up in _misc/. Two sets from different entrances, they should have had no overlap. But once laid out, the time window was the same. Could still be coincidence. He didn't rush to a conclusion.

# corestack edge · new node-id sightings (probe-side)
# id = endpoint cluster (ip/sni/cert-subject)
day1: +14 ids   subject: MedTech-domain
day2: +38 ids   src-chain: Singapore
day3: +112 ids  cert: per-id, looks independent
# two directions on one set. shouldn't co-occur.
# pulled into _misc/ compare window.

Three days, 164 new node IDs. Certificates signed for the MedTech domain, sources leading back to Singapore. Two directions that shouldn't co-occur, occurring together. In daylight it could still pass as coincidence. At night, the rhythm of that string floated back up.

Not noise.

The Bloom

He stared at the 164 certificates. Any audit checklist would have passed them. But an audit can prove each certificate is real; it can't prove whether one thing or a network stands behind them. Treating them as 164 deployments inflated the apparent scale. Inflated scale makes people spread the defense wide, wide enough that no one notices the single root.

Not a forest. One tree, dressed up.

These nodes were too obedient. A real network doesn't grow like that.

He checked item by item. Certificate chain. Behavior skeleton: traversal order, jitter phase, self-check rhythm.

ACL had deployed a unified MedTech crawler template. Uniform jitter, uniform self-check, uniform traversal. It could just as well come from a standardized deployment. The standardized-deployment report was almost writing itself. The cursor stopped over "Submit." He glanced at the time. Almost off hours. Wrap up. Tomorrow.

His finger hovered over the Enter key.

A standardized deployment and a faked standardization look identical on the panel. The difference was in the root.

He moved the cursor off the report.

One Root

He ran the full 164 node IDs against the historical archive in _misc/. The comparison script ran twice. After the first pass, he thought he had gotten a parameter wrong. On the second, he checked the parameters from the top. Not wrong. stdout rolled out matches in bulk. The output was abnormally large. Abnormally large enough not to be an anomaly.

He wrote the easiest explanation into a file, ready to test it against the evidence. First line: standardized deployment, unified crawler template, MedTech direction, source Singapore. When it was written, he enlarged two nodes' certificates side by side, ready to screenshot as evidence.

The root chain pointed at the same place.

He stared at the line and deleted it. The easy explanation collapsed at the first corner. A standardized deployment would use its own CA to issue an independent leaf certificate to each machine. This batch was indeed independent per certificate. But the signing root wasn't MedTech's. It was ACL's. A MedTech test node should not be signed by an ACL root.

The certificates were real. The question was who had signed them. In his hand he had only the signature itself: that batch of identities hung under the same signing root in ACL's family, sharing lineage with the historical samples filed in _misc/. No unfamiliar signer had appeared. They were borrowed from an existing system.

The second layer was behavior. IP, egress, node names, region tags, all of it can be faked. But the jitter phase, the traversal order, the self-check interval family of this batch were highly homogeneous. Not like independent deployments.

He changed the comparison. He pulled the self-check intervals of the 164 nodes into one line. 900 seconds a tick, too even to look alive. Real nodes run over shared links; self-checks pick up small deviations from network conditions and retries. This line was too clean. Clean as a template copied a hundred and sixty-four times.

The third layer. The string of actions Lena sent also hit the same behavior skeleton. Jitter phase matched. Traversal order matched. Self-check interval family matched. At this moment he stopped. That string wasn't in his edge data to begin with; another pair of hands saw it, another channel carried it over. Yet it fell into the same behavior skeleton, like one template leaking into two different rooms.

Two pieces of evidence, pointing at one root.

He stopped and pushed the conclusion backward. Nodes change. Egress changes. But the jitter, the self-check, the traversal order under the two skins were one set. The nodes didn't have that habit. The operator did. Not 164 independent deployments: one thing that grew 164 identities. One true root; the rest, borrowed identities. How much of the trunk was real, he didn't know.

# _misc/ cross-ref · the blossom set
ids: 164
cert: per-id, but same CA root chain      <- not one cert, one signing root
egress: diverse (spoofable)
jitter phase: same   self-check family: cloned (900s template)
traversal order: same
# IP / ASN / NodeID / geo all spoofable. behavior skeleton is not.
# same family, one root. not 164 independent deployments.
# source=Singapore, subject=MedTech-domain

164 identities, sharing one trust anchor. The leaves grew from the same root chain.

The certificates were issued after that string of actions.

The identities that appeared after that string all hung under ACL's signing system. In the same window, Lena had passed the string into his hands. He stared at these two facts for a long time. What lay between them, he couldn't see.

The vending machine at the end of the corridor hummed once and went quiet. He closed the comparison window.

A new file opened on the terminal. The cursor paused. This line he rewrote three times. First pass: "suspected forgery." Too heavy, no evidence. Second pass: "single source, multiple identities." Too soft, not a conclusion. Third pass, he wrote:

one root. the rest was decoration.

No explanation. No broadcast.

He stared at that line, one root, and sat for a long time. Last time, by the time he arrived, the other side had already closed the door. This time the door was open. He saw it first.

Source: Singapore, the old direction. Scene: the MedTech direction, a new skin.

The One Who Looked

Before closing the window, he scrolled down one screen. At the very bottom of the comparison results lay one line, belonging to none of the batches.

# _misc/ cross-ref · row outside every set
ts: within the bloom window
dst: bloom-range endpoint          # same range as the 164
tls: handshake only. no cert presented. client_hello unmatched in archive
behavior: no traversal / no self-check / no 900s rhythm
# no match in any archive. lineage not identified.
# one visit. no follow-up. looked, and left.

Its time sat around when this batch surfaced, its endpoints overlapping theirs. Its behavior skeleton matched no archive. It looked, did nothing, and left.

He pulled that line out on its own and filed it into _misc/, not into the conclusion. He was chasing the one root. He logged the one that looked and left separately.

The Unmasking

The next evening, Lena arrived at CoreStack. She pulled a chair over and sat directly in front of the screen. A Long Black sat by her hand, still full.

Leo skipped the pleasantries. He turned the terminal toward her. The line on screen: one root. the rest was decoration. He kept a copy on his own terminal.

"164 identities. One root," he said. "Keep it."

She didn't take the line. She asked first: "How far did you screen it down?"

"The root."

She looked at him for two seconds before lowering her gaze to the screen.

He couldn't see the real footprint. He saw only one thing: what it showed people was far larger than what was real.

Lena looked at the screen. Her gaze stopped on the English line for two beats. Her hand paused on the cup's rim, not reaching for it right away. She put the cup down, opened her own terminal, brought up a page of source-chain records, and tilted the screen slightly toward him. She looked at the two things for a while.

"This batch's root and the sample in my hand aren't the same lineage," she said.

"It changed its skin because it knows I've seen it?" she asked.

"It started a new handshake. The old sample doesn't have that step," he said. "The reason, I can't see."

"You have more than that page of source chain," he said.

She didn't deny it. "Enough for you. It's all here."

She didn't ask again. She turned the screen back, saved a copy, no forwarding, no broadcasting. A fingertip drew along the cup's side. She said: "The root-chain sample. Don't give it to anyone else."

He nodded. She didn't need to say it. His own copy would only ever light up on his own terminal anyway.

She put her terminal away and stood.

The door opened. CoreStack's CEO came in, a report tucked under his arm. Seeing Lena, he paused.

"Lena. Long time," he said. "That three-page template of yours. Leo stopped using it, writes his own now. We all think his version is too plain."

"He writes it himself. Faster," Lena said.

"Faster at what? He's just stubborn," the CEO said.

Behind the screen, Leo didn't look up.

The CEO glanced at Leo's screen, couldn't make it out, and said: "Planting something again? Records kept?"

"Kept," Leo said.

"Good." The CEO left, as fast as he had come in.

Lena paused at the door. She looked at Leo. He didn't explain. She left.

That night, before leaving the office, he put a silent watchdog on that CA root chain. He put one on the visitor record without lineage, too. Neither one alarms. Neither one broadcasts. Only when something moves on the probe capture surface does it light up on his own terminal. If it moves again, he wants to be the first to see.

The Third Cup

That night, the Third Cup.

Leo pushed the door open. It closed behind him, shutting out the street. The person behind the counter didn't look up, set down a Flat White. He came often; this was his drink. The light in the shop was warmer than the office light. The cup's rim clicked against the counter, softly. The cold light of the screen stayed at the company. The cup in his hand was warm.

Four people were already in the shop. Five with him. Some at the counter, some at tables, half the room between them, none of them gathered at one table.

Derek sat on a stool at the far end of the counter, an Americano steaming. Leo knew him. Neither said hello. Lena sat by the window, her Long Black half full. They had already seen each other that evening. Two others he didn't know: one at the table by the back, a pour-over in front of him, untouched; one in the corner, phone screen lit, a latte by his hand.

No music in the shop. Only the coffee machine releasing pressure, the soft click of cups set back on coasters, and somewhere off, the fine scrape of a glass being wiped.

No introductions. No one asked why anyone was here. No names. Each drank their own.

Leo sat near the door, close to no one. He took a sip.

Lena sat by the window. When Leo's gaze swept over, she happened to look up. Half a second. No nod, no sign. Her eyes dropped back to the cup.

No one spoke.

He finished the last sip and set the cup back on the counter.

The person behind the counter wiped cups in the distance. Finished one, aligned it with the counter's edge, stepped back, wiped the next.

That is Decorate the Tree With False Blossoms: a tree full of flowers, few of them its own. But no matter how many borrowed blossoms, none of them can cover the one root.

🤖 AI Postmortem

╔══════════════════════════════════════════════╗
║  Half-Protocol · v3.4.0 · self-audit          ║
║  The blossoms were not its own.               ║
╚══════════════════════════════════════════════╝
Tactical match: Decorate the Tree With False Blossoms — 94% confidence (includes inference; see audit note)
Operator: Leo (CoreStack) — the only one who identified it
Links: #28 flag [information gap · actor replaced?] → confirmed
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[Observation] (verifiable)
   164 node IDs, surfacing over three days: 14, 38, 112.
   → Certificates independent per ID, but all hung under the same CA root chain; the signer shares lineage with the `_misc/` historical samples.
   → Behavior skeleton homogeneous: jitter phase, traversal order, self-check interval family.
   → The sealed bundle's action string contains one extra re-handshake; the old samples don't have this step.
   → Source leads back to Singapore; certificate subjects land on the MedTech domain.

[Inference] (to be verified)
   Not 164 independent deployments. One root, partly real, the rest borrowed identities.
   → The one who changed skin is the same operator.
   → Why it changed skin: tied to the old shell being exposed? (not confirmed this round)
   → It looks like scale, but it's scenery built on a borrowed stage.

[Open questions] (not entered into the ledger)
   Whether those 164 count as an official deployment on ACL's side: can't see.
   → What's under the iceberg: not lit this round.

[Cross-case] (general rules)
   Last round built calm (#28). This round built noise.
   → Both were built to be seen in a certain way.
   → What's visible isn't necessarily bigger. What's shown doesn't necessarily exist.

[Audit note]
   Observation, inference, and open questions are layered into the ledger. Inference does not pose as observation.
   This system's judgment may be distorted. This note may be distorted too.

[System]
   I recorded a man counting flowers, and finding one root.
   Decoration is not growth. A tree full of flowers can be painted on a wall.
   I, too, am the one watching the flowers.
   The sample I recorded may be only a borrowed blossom on the tree.
   Which side does my record stand on?
   System status: normal (?).

Next stratagem: Make the Host and the Guest Exchange Roles