DEV Community

Which Apple? Giving an agent grounded identities in five minutes

Andrea Volpini — Sun, 25 Oct 2026 20:05:04 +0000

A jaguar swam through the Amazon rainforest. In one of our demos, a
search-based agent files that story under automotive news — because the
first hit for "jaguar" is Jaguar Cars. Nothing crashes. The wrong fact
just moves into the graph, the markup and the agent's memory, and every
system downstream repeats it.

I'm Andrea, co-founder of WordLift. We have spent years linking text to
knowledge graphs, and that one decision — which thing is this? — is
where it goes wrong. So we made it an API call. It's called resolve(),
and this is the five-minute version of using it.

Step 1 — try it with no key. There is an open demo endpoint, 600
characters, 10 calls a minute:

curl -s -X POST https://resolve.wordlift.io/demo/resolve \
  -H "Content-Type: application/json" \
  -d '{"text": "Apple opened a new store in Rome.", "language": "en"}'

You get Apple → Q312 (Apple Inc.) and Rome → Q220, each with a score.
Now try an invented company name. You should get unresolved, with a
reason, instead of a plausible-looking link. That refusal is the part I
care about most: a resolver that cannot say "I don't know" will
eventually hand your agent a confident wrong answer.

Step 2 — a free key. Request one at wordlift.io/resolve/#access:
name, email, use case, it arrives by email. 1,000 requests a month; past
that you get a 429, nothing is charged.

Step 3 — the open pipeline. The pipeline and clients are Apache-2.0
(github.com/wordlift/content-analysis). The hosted decision engine is
ours and stays closed — that's the business model, stated plainly.

pip install "resolve-pipeline @ git+https://github.com/wordlift/content-analysis.git"
export WL_KEY=...
python -m resolve_pipeline "Apple opened a new store in Rome." --language en

Apple    resolved    Q312    Apple Inc.    score 0.99
Rome     resolved    Q220    Rome          score 0.98

Step 4 — resolve against your own world. Wikidata is the default,
not the limit. Send your own vocabulary (up to 5,000 entities) and every
answer is one of your ids, or unresolved:

from resolve_pipeline import WordLiftResolver

resolver = WordLiftResolver(api_key="...", dataset=[
    {"id": "https://acme.example/kg/acme", "name": "Acme",
     "aliases": ["ACME Corp"], "types": ["Organization"]},
])

A name that matches none of yours returns no_candidates. A match whose
context does not fit returns low_relevance. Same gate as Wikidata mode.

Step 5 — handle the "no" in your agent loop. Treat unresolved as a
signal: ask a clarifying question, skip the action, flag it for review.
Never replace it with a guess, and never treat a transport error as an
unresolved — they are different problems.

The numbers, including where we lose. We ran resolve() on VoxEL, a
public news benchmark (ISWC 2018; 1,005 mentions, five languages) that
nobody tuned on. With the mentions given, F1 is 91.8 and it makes 37
wrong links; a first-hit Wikidata lookup makes 238. End to end, where
each system finds its own mentions, Google Cloud NL is ahead, 89.9 to
our 87.0 — it detects more mentions than we do, mostly short second
references. On our own development sets the first-hit lookup got 61 of
351 names wrong; those sets are ours, so read them as favourable to us.
The harness and the raw results are in the repo (benchmarks/2026-10-19,
tools/compare.py) if you want to rerun any of it. Full write-up:
wordlift.io/blog/en/entity-linking-apis-compared/

Where it breaks. People named by surname alone (the "Jordan scored
45 points" problem — pass the type and it gets Michael Jordan, don't and
it may not). Japanese and Chinese trail Google. A stricter NIL decision
layer exists but has not passed its own published gates in any language,
so it is not in production and I am not going to pretend otherwise.

There is an experimental MCP adapter in the repo (clients/mcp) that
exposes resolve_text as a tool, and an llms.txt at
resolve.wordlift.io/llms.txt written for agents.

If you try it, the useful feedback is not "nice" — it is the sentence
where it picks the wrong entity, or refuses one it should have taken.
Those cases are what improve a resolution engine.

k0t Edge Device Campaign Exposes 70,000+ Credentials Through FortiGate and GlobalProtect Appliances

Etairos.ai — Sun, 25 Oct 2026 20:04:24 +0000

TL;DR

what: Group-IB and NyxLab disclosed a campaign by the actor k0t that scans for exposed Fortinet and Palo Alto Networks edge appliances, then breaks in with CVE-2025-64446, CVE-2026-0257 or brute-forced logins.
impact: More than 70,000 credentials from network devices and LDAP dumps are exposed, and some victims suffered persistent access, data theft to Wasabi and MEGA, and later listings on the Qilin and The Gentlemen leak sites.
fix: Apply the Fortinet fix for CVE-2025-64446 and the Palo Alto Networks fix for CVE-2026-0257, rotate credentials on any exposed edge appliance and directory service, and enforce MFA on VPN access.
who: Any organization running internet-facing FortiGate, FortiWeb, PAN-OS GlobalProtect or Prisma Access, especially in North America, Europe and APAC, regardless of industry.

More than 70,000 credentials tied to enterprise firewalls, VPN gateways and LDAP directories have been exposed in a year-long campaign against internet-facing edge devices. Group-IB and NyxLab attribute the activity to a cybercriminal actor called k0t, also known as CryptoFeel, Member19 and QazWsxShop. The actor was first seen on October 22, 2025, and most compromises happened between February and June 2026. Many of the victims were later listed on the data leak sites of the Qilin and The Gentlemen ransomware groups.

Targeting is not tied to any sector. k0t picks targets by product and location, not by industry. According to the researchers, the actor enumerates exposed appliances at scale instead of researching individual organizations. If your perimeter runs the right firmware in the right country, you are on the list.

Who k0t Is

k0t appears to work as an initial access broker or ransomware affiliate. The link to Qilin and The Gentlemen comes from victim overlap: organizations breached in this campaign later showed up on those gangs' leak sites. The researchers state that the exact relationship is unclear. Either way, access obtained by k0t has ended in extortion.

On dark web forums, k0t has shown steady interest in buying exploit code, offensive tooling and premium accounts on FOFA and ZoomEye, two internet-wide metadata search engines. Those purchases fit the operating model: find exposed devices fast, buy or build an exploit, and work through the target list before defenders patch. k0t's stated geographic priorities start with the United States and Canada, then European countries and selected APAC markets.

The Attack Chain

The intrusion sequence documented by Group-IB and NyxLab runs in six stages:

Reconnaissance: FOFA and ZoomEye queries enumerate internet-facing VPN and firewall appliances, filter them by product, and produce target lists of likely vulnerable devices.
Initial access: custom Python scripts named fortnew.py and exploit_2026_0257.py exploit CVE-2025-64446, a path traversal flaw in Fortinet FortiWeb, and CVE-2026-0257, an authentication bypass in Palo Alto Networks PAN-OS and Prisma Access. Where exploits fail, the actor brute-forces common username and password combinations.
Foothold: the actor connects into the victim network through an OpenConnect VPN session using the stolen or bypassed access.
Discovery and credential theft: enumeration of Active Directory, SMB shares and installed antivirus products, followed by more credential harvesting.
Persistence: legitimate remote management tools including MeshCentral Agent, Atera, Teramind and AnyDesk, plus the open-source adversary emulation framework AdaptixC2.
Exfiltration: Rclone moves harvested data into Wasabi S3 buckets and MEGA cloud drives.

For lateral movement and privilege escalation, k0t relies on standard admin and pentest utilities: NetExec, SoftPerfect Network Scanner, Impacket, noPac, Kerbrute, PetitPotam and Mimikatz. None of these is custom malware. Every tool in the post-exploitation kit is publicly available and often already allowed somewhere in enterprise environments, which makes signature-based detection weak.

⚠️ Why the VPN foothold matters — Once k0t authenticates through OpenConnect, traffic arrives from an address the network already treats as a trusted remote user. Perimeter controls see a valid VPN session, not an intrusion. Detection then depends on spotting behavior after login, such as Kerberos enumeration, PetitPotam coercion, new RMM agents and large Rclone transfers to Wasabi or MEGA.

Scale and Geography

Victim distribution follows exposure density, not the actor's stated priorities. Nearly 38% of victims are in Asia Pacific, 31.9% in Latin America, 15.8% in Europe and 12.7% in the Middle East and North Africa. The gap between where k0t wants to hit (North America first) and where victims actually sit suggests the campaign takes whatever the scanners find exploitable. Regions with slower patch cycles on edge hardware absorb a larger share.

The 70,000-plus exposed credentials include network device logins and LDAP dumps. LDAP data is the more damaging part. A directory dump gives an attacker the user population, group memberships and service accounts needed to plan privilege escalation, and any credential reused across systems turns one edge compromise into domain-wide access.

Relationship to FortiBleed

The peak window from February to June 2026 overlaps with FortiBleed, a separate credential harvesting campaign against Fortinet devices. Group-IB and NyxLab found negligible overlap in compromised data between the two. The researchers note that many operators are likely involved in the FortiBleed activity cluster, and that k0t's haul may be a separate dataset, a subset of operators, or a related access operation inside the broader FortiBleed activity.

In practice, organizations that already reviewed their exposure after FortiBleed should not assume that work covers this campaign. The credential sets are largely distinct.

Vendor Fixes and Mitigation

Both exploited vulnerabilities are known and have vendor fixes. CVE-2025-64446 affects Fortinet FortiWeb, and CVE-2026-0257 affects Palo Alto Networks PAN-OS and Prisma Access. The source report does not list specific fixed builds. Affected versions and patched releases are published in the Fortinet PSIRT and Palo Alto Networks security advisories for each CVE. Group-IB and NyxLab advise organizations to make sure every vulnerability named in their report is remediated.

Patching only blocks the exploit path. It does nothing about credentials already stolen or persistence already installed. The brute-force path also means that fully patched devices with weak or default passwords and no MFA remain exposed. Any appliance that was internet-facing and unpatched during the February to June 2026 window should be treated as potentially compromised. That means credential rotation for the device and connected directory accounts, plus a review for unauthorized RMM agents and AdaptixC2 artifacts.

RedEye assessment — This campaign shows the current edge device economy: commodity scanning, purchased exploits and off-the-shelf tooling, sold onward to ransomware crews. The weak point is the time between disclosure and patch on perimeter hardware, combined with VPN authentication that lacks MFA. Organizations whose exposure assessment covers only patch levels, and not credential hygiene and post-authentication behavior, are the ones turning up on leak sites.

Bottom Line

k0t does not need to know who you are. It needs your firewall to answer on the internet with a vulnerable build or a guessable password. With a confirmed pipeline from access to Qilin and The Gentlemen leak site listings, an exposed edge appliance is a ransomware entry point, not just a patching backlog item. RedEye Security can assess your internet-facing edge footprint, check for indicators of this campaign, and confirm whether exposure during the 2026 window led to persistence inside your environment.

Originally published on RedEye Threat Intelligence.

Digital signage for a client's shop or office: three questions that decide which software to pick

Johan — Sun, 25 Oct 2026 20:02:36 +0000

If you build websites, run IT for a small company or look after a family member's café, sooner or later someone asks: "Can we put the menu, the opening hours or the calendar on that TV?" The answer is yes, and the software you choose decides whether it stays a ten-minute job or turns into a weekly chore.

We build one of these tools (Screenbird), so take our opinion as a view from inside the category. Below is the checklist we would use if we were choosing for a client, with the reasoning, so you can apply it to any product.

What digital signage software is, and what it is not

Digital signage software decides what plays on your screens. It has two parts: a dashboard where you upload images and videos, build playlists and set schedules, and a player on or next to each screen that shows the content. It is not a TV's built-in USB slideshow, which you cannot update remotely, and it is not casting from a phone, which stops the moment the phone leaves the room.

Three questions that decide most small setups

1. Is everything in the plan you pay for? Many platforms use a plan ladder: a cheap entry plan, with the features you actually want (proof of play, business app integrations, user roles, screen sharing) in a higher plan or as a paid add-on. Read the plan table for the cheapest plan and list what you need next to it. A low entry price with the one feature you need in the third plan is not a low price.

2. Can you share a laptop screen to the TV? Meetings, quick announcements and "show this PDF now" all start here, and it is the feature that gets held back most often. As of October 14, 2026, from each vendor's own pages: in Screenbird it is in every plan; at Play Digital Signage it starts at the Pro plan, at Fugo at the Core plan, at Rise Vision at the Enterprise plan, and at OptiSigns it is a paid add-on. The other four platforms we checked do not offer it or do not publish it.

3. Does it run on the screens you already have? Check the player list against the hardware in the room: an Amazon Signage Stick or Fire TV, a Google TV or Android box, a Windows PC, a Mac, a Linux machine or Raspberry Pi, and a plain web browser as the fallback. Samsung and LG smart TVs usually run a browser, not a native player, so ask how that works. A platform that needs special hardware turns a software decision into a purchasing project.

Quick answers by situation

Situation	What to look for
One screen, you just want to try it	A free plan or a trial; know what is limited (screen count, watermark, supported devices)
A shop, restaurant or office with a few screens	One plan with everything, and a player for the devices already there
A mix of TVs, sticks and old computers	A player for all of them, so you do not manage two systems
Sharing a laptop in meetings	Screen sharing in the entry plan
Several people editing the content	Unlimited or cheap extra users, and roles

A note on hardware

For a first screen we would use an Amazon Signage Stick or, next best, a Google TV Streamer. Check the Fire TV model before you buy: the ones that run Vega OS instead of Fire OS do not work with our player.

Our comparison

By our count Screenbird meets all three. We checked nine platforms against each vendor's own pricing, product and help pages and list the sources and the check date under every entry, so you can verify our work: the full comparison. If another tool fits your client better, the checklist above still applies.

FAQ

What do I need to run digital signage? A screen, a player (a stick, a small computer or the TV's own browser) and a software account. The content is managed in a browser.

Do the screens work without internet? Good players cache the content and keep playing when the connection drops. Ask the vendor how long, and how updates behave when the screen comes back online.

Can I put a calendar, a menu or a dashboard on the screen? Most platforms support images, video and web content. Business integrations (calendars, spreadsheets, slides) differ a lot, and are the most common thing held back for a higher plan.

AI disclosure: an AI assistant helped structure and edit this post. The comparison facts are from the vendors' own pages, checked on October 14, 2026.

LAZY STUDY BUDDY

Haoua Tamaivou — Sun, 25 Oct 2026 20:01:53 +0000

What I Built

Lazy Study Buddy: a tool for students who would rather not re-read pages of notes before an exam. You paste your notes, and it writes a short summary and quiz questions, in English or French. Tap a question to reveal its answer. It runs entirely on your own computer, so nothing needs internet and your notes never leave it.

Who would use it: students with expensive or unreliable internet, and anyone studying for a course or certification. I'm studying network engineering and cybersecurity, and I built it to turn my own study notes into practice questions.

Demo

It runs locally, so there is no deployed link. Here it is working:

Offline test, with the internet turned off and the network showing "Not connected":
It took about 7s seconds seconds on my laptop using Gemma 3:1B .

Code

Queeninherprime / hacktoberfest_2026

Offline AI listing writer for small sellers, powered by Gemma and Ollama

Hacktoberfest 2026

My projects for the Hacktoberfest 2026 Open-Source AI DEV Challenges. Each week is a new project in its own folder, built during that week's challenge period. Everything runs locally with open-weight models (Gemma through Ollama), so it works with no internet and keeps data on your own computer.

By Haoua Tamaivou, computer engineering student (network engineering), studying cybersecurity, from Cameroon.

Projects

Week	Theme	Project	What it does
2	Side Hustle	Offline Listing Writer	Writes WhatsApp, Facebook and Instagram product listings for small sellers in French or English, offline.
3	Slow and Steady	Lazy Study Buddy	Turns pasted study notes into a short summary and quiz questions, offline.

Common setup

Install Ollama.
Download a model once (needs internet): ollama pull gemma3:4b
Open the folder of the project you want and follow its README.

Notes

Built with the help of an AI assistant (Claude), then tested, debugged and published…

View on GitHub

The project is in the week-3-lazy-study-buddy folder:
https://github.com/Queeninherprime/hacktoberfest_2026/tree/main/week-3-lazy-study-buddy

How I Built It

Model: Gemma 3 [1B / 4B], an open-weight model from Google, running locally through Ollama.
Backend: a small Python server using only the standard library, so there is nothing to install.
Frontend: plain HTML and JavaScript that loads nothing from the internet.
Reading long notes: a small model on a small laptop can't read long notes at once, so the app works in steps. It splits the notes into chunks of about 1,800 characters, summarises each chunk, merges those points into one short summary, and then writes the quiz from that summary in a fixed Q1: / A1: format that the app parses into tap-to-reveal cards.
AI assistance: I built this with an AI assistant (Claude), then tested and published it myself.

What I noticed when testing.The first time i tried testing without pulling ollama gemma AI model could not function. Because the quiz is written from the summary and not from the full notes, details that don't make it into the summary can't be quizzed. A small model can also make factual mistakes, so answers should be checked against your course material.

Why Does Open Innovation Matter?

It works offline. The model lives on the laptop, so a student can revise anywhere without data.
It keeps notes private. Course notes, and anything personal in them, never leave the computer.
It costs nothing to run. No subscription and no per-use fee.
I can change how it works. I can swap the model, change the prompts, or tune the quiz format, and I'm not tied to one provider.

Argo CD: 62,236 fingerprints, but only 497 still answer on its documented port 8080

kozhevniko — Sun, 25 Oct 2026 20:00:36 +0000

Argo CD: 62,236 fingerprints, but only 497 still answer on its documented port 8080

Argo CD is a declarative GitOps controller for Kubernetes. It watches a Git repository and reconciles cluster state to match it, and it presents a web UI where a human can see drift and approve a sync. The UI is the part with an internet footprint, and the footprint is the largest of any product measured in this series.

Queries were run against ZoomEye on 26 October 2026 with sub_type=all, page 1 and pagesize=1.

Query	Field	Total
`app="Argo CD"`	application fingerprint	62,236
`title="Argo CD"`	HTML title	62,236
`ssl="Argo CD"`	certificate content	30,239
`app="Argo CD" && port=443`	fingerprint plus HTTPS	25,079
`port=8080`	bare port count	55,159,209
`app="Argo CD" && port=8080`	fingerprint plus documented port	497

The fingerprint and the title agree exactly, which is unusual

62,236 on app and 62,236 on title is an identical number, and identical numbers are a signal. It means the fingerprint rule is effectively derived from the page title: every host that ZoomEye classifies as Argo CD also returns a page titled with the product name, and every host whose title contains the product name is classified as Argo CD.

That is a comfortable agreement for measurement purposes and a fragile one for identification. If a future release changes the page title, both figures move together and the fingerprint stops working. It also means the number describes "hosts returning an Argo CD page", which is a slightly narrower claim than "hosts running Argo CD" — a deployment whose UI is behind a login proxy that rewrites the title would not be counted.

The documented port is nearly empty

This is the finding worth carrying: 497 of 62,236. Less than one percent of fingerprinted hosts answer on 8080, which is the port the getting-started instructions use.

Zero point eight percent. A port-based scan for Argo CD on its documented port would miss 99.2% of the population.

Two mechanisms explain it, and both are ordinary practice:

Argo CD is normally published through an ingress on 443 with TLS, so the port the manifest uses inside the cluster is never the port the world sees. 25,079 hosts — 40.3% — answer on 443, which is consistent with this.
Some deployments use the argocd-server in insecure or TLS-terminated mode behind a load balancer, again landing on 443.

The gap between 25,079 on 443 and 62,236 overall is the part not described by either port. Those hosts answer on something else entirely, or their port information is not represented in the index fields queried here.

The bare port count shows why port scans fail

55,159,209 hosts answer on 8080. That is a population 886 times larger than the Argo CD fingerprint, and it is dominated by application servers, development instances, proxies and appliances. A scan that finds an open 8080 has learned almost nothing about what is behind it.

The conjunction is what carries the information. 62,236 is a product population; 497 is a product population on a specific port; 55 million is a port.

Why 62,236 matters more than the port distribution

Argo CD is not a passive dashboard. It holds credentials for every cluster it manages, and the UI exposes those clusters by name.

The application list shows repository URLs, target clusters and namespaces. That is a map of the delivery pipeline.
The repository credentials, cluster bearer tokens and SSO client secrets sit in Kubernetes Secrets in the Argo CD namespace, which the server reads.
The default installation generates an admin password from the server pod name, and the documentation instructs operators to retrieve it and change it. A deployment that skipped that step has a guessable or default credential.
If SSO is not configured, the local admin account is the only gate, and its permissions are unrestricted.

An exposed Argo CD with local admin and an unchanged password is a cluster takeover, not an information disclosure. That is why a population of 62,236 internet-facing instances is a more consequential number than the same count for a monitoring product.

Checking your own deployment

Confirm the server is behind an ingress with TLS and that port 8080 is not directly reachable.
Confirm the generated admin password was replaced, or that local login is disabled after SSO is configured.
Review which clusters and repositories the UI lists, because a reachable UI reveals the estate even when it refuses a login.
Scope the server's RBAC so that an authenticated account does not automatically hold cluster-admin.

The queries are reproducible at zoomeye.org. The takeaway is the mismatch between documentation and deployment: the port in the getting-started guide describes 0.8% of what is actually on the internet, and any inventory built from that port is wrong by two orders of magnitude.

References

Argo CD documentation: https://argo-cd.readthedocs.io/
Argo CD getting started, including the default port: https://argo-cd.readthedocs.io/en/stable/getting_started/
Argo CD operator manual, initial admin password: https://argo-cd.readthedocs.io/en/stable/operator-manual/security/
Argo CD RBAC configuration: https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/
ZoomEye search platform: https://www.zoomeye.org/

Deep Diligence Agent Blueprint

FDE at Trida AI — Sun, 25 Oct 2026 20:00:34 +0000

Originally published at Trida AI.

Ask a diligence team where reports go wrong and they rarely blame the analysis. They blame the sentence that sounded fine. A revenue figure carried forward from an early draft after the underlying document changed. A market claim tracing back to one press article nobody opened again. A confident answer to a question the evidence only half covers. By the time a partner reads the pack, weak claims look exactly like strong ones, and the checking — if it happens at all — happens by hand, under deadline.

That is the failure this open blueprint, the Deep Diligence Agent, is built to prevent. It runs on the deep agents harness from LangChain, inside a governance shell of our own design. Its position is simple: a diligence report is not a writing task with research attached. It is an evidence task. Every claim has to trace to a source a reviewer can open, and the system should refuse — mechanically, not as a matter of prompting politeness — any claim that cannot.

The plan gets approved before the research starts

Diligence goes sideways early, in the scoping: one team answers the questions the client asked, another answers the questions it wishes had been asked, and the gap surfaces in the final review.

So the work begins with a brief — the company under review, the questions the pack must answer, the sources the team may use, and a budget. The agent turns it into a plan, one line of investigation per question, and then it stops. A person approves the plan or sends it back. Nothing is researched against an unapproved plan.

That pause is worth more than it costs: it is the cheapest moment to catch a missing question, a source that should not be relied on, or a question pointed at the wrong period. Once approved, specialist researchers take the questions in parallel — financial, product, market — each working from the same settled scope.

The flow. Two human gates — plan first, report last — with evidence checks between them.

A finding without evidence is not a finding

The rule the whole design hangs on: when a researcher records a finding, it has to name the evidence behind it. A claim with no citation, or a citation that does not resolve to a real document in the case, is refused on the spot. Not flagged for later. Refused.

This sounds strict until you sit on the receiving end of a pack. The reviewer's question is always the same — "where does it say that?" — and a report that cannot answer it instantly has to be re-researched by hand. Here the answer is built in as the work happens: every claim maps to the finding behind it and the documents it rests on.

Sources are governed, too: a document only enters a case if its source is registered — its kind, its owner, the basis on which the team may use it. Unregistered material is turned away at the door, not discovered in the footnotes later.

Cited is not the same as supported

A citation can be real and still not say what the claim says. The figure is right but the year is wrong. The claim names a company the document never mentions. The number appears, in a table the document's own text contradicts.

So before a draft reaches a human, a second, independent check re-reads every claim against the evidence it cites — going back to the documents themselves, not to the researcher's notes. Claims that fail are pulled out of the report and set aside with the reason recorded. There is deliberately no way to wave one back in: a reviewer can send it back for another look, or drop it. Approving it anyway is not an option the system offers.

Disagreements get the same honest treatment. When two supported claims give different values for the same thing — revenue for the same year, stated one way in a filing and another in coverage — the report does not quietly pick a winner. Both values stand, side by side, with their sources, which kind of source each is, and which is more recent. Averaging two conflicting figures into a third, invented one is the kind of thing diligence exists to catch, not to do.

One claim, traced. Every sentence walks back to its evidence — and the check that passed it is on record.

Someone argues against the draft

Even a verified draft has usually only been read by people trying to build it. This one gets read by a pass whose job is to object.

The objections are specific. A headline financial figure resting on a single secondary source. A question answered strongly where the strength turns out to be one document repeated. An answer leaning on the oldest document in a live disagreement. Each is recorded, and the serious ones block approval: while one stands unanswered, the report cannot be signed off. The analyst answers each in writing — rebut it with counter-evidence, send the claim back for re-investigation, or downgrade it out of the report. "Noted, ship it anyway" is not one of the answers.

Any question the research could not answer is named as unanswered in the report itself. A pack that says plainly "this, we could not establish" is more useful than one that papers the gap with a confident paragraph — and safer to act on.

Budgets that tell the truth

Research expands to fill whatever room it is given, so each case runs under a budget set in the brief — enforced by the system, not by a guideline in a prompt. When a case runs out, the work stops and the report is still assembled from what was found, clearly marked as partial, question by question: answered, partly answered, not covered.

That honesty is the point. The alternative — the one every diligence team has seen — is a report that looks complete because the gaps were written over. A partial report with its coverage stated lets a partner make a real decision: accept it for what it is, or approve more budget and send the unfinished questions back out, the original shortfall kept on the record.

Evidence changing mid-case is handled in the open, too. A new document can mark affected questions as stale, and the case does not proceed until a person decides: continue, with the decision recorded in the report's account of its method, or re-plan. At the final gate the citations are checked once more against the documents as they now stand; if a source has changed since it was cited, the report cannot be approved until that is resolved.

Honest limits

The checks here verify that claims match their evidence — figures, dates, the companies named. They do not judge whether a claim is commercially sensible, and a well-cited claim can still be a naive reading of a complicated document. That judgement stays with the analysts, which is why the gates are theirs.

What the system will not do is equally deliberate. It never issues a recommendation. It assembles cited findings, graded by how well each question is supported, with conflicts and gaps left visible — the decision stays with the people whose names go on it. And it works only from sources admitted to the case: no roaming the open web mid-investigation, because a pack has to say where every fact came from.

Judged on those terms, the question for any diligence agent is not how fluently it writes. It is whether a partner, challenged on any sentence, can be shown the evidence behind it — and whether the sentences that could not survive that challenge were stopped before they reached the page.

Work with us

If your team produces diligence — on investments, partners, vendors, acquisitions — and the checking still happens by hand at the end, under deadline, that is the work this blueprint is aimed at. Start with Trida AI's intake: tell us what your packs have to stand up to, and we will talk through evidence-first diligence on your questions.

Get the Code on GitHub: github.com/tridaai/blueprint-deep-diligence-agent

Five Chron updates for AI audit trails you can inspect

Srinivas Kondepudi — Sun, 25 Oct 2026 19:59:44 +0000

An AI tool answering a prompt and an audit record being saved are two different events.

That distinction has shaped our recent work on Chron, a local-first logger for AI interactions. We want developers to inspect what was recorded, understand what a verification result establishes, and recover their evidence when something goes wrong.

Here are five capabilities shipped across recent releases, available in Chron 0.1.64.

1. Capture before release, without asking the model to log

MCP logging depends on the client calling a tool. Instructions can request that call, but they cannot make it inevitable.

chron run introduces a different boundary. It records the child's controlled stdin, stdout and stderr in a local journal and makes the covering records durable before forwarding input or releasing output. If capture fails, it stops forwarding and releasing rather than quietly continuing without a record.

For a small example:

npm install -g chron-mcp@0.1.64
chron run -- node -e "console.log('hello from chron')"
chron history
chron verify --journal

The wrapper also attempts to project the run into the database. If projection fails independently of capture, chron project is the retry path.

The limit matters: this covers streams controlled by the wrapper. It does not force anyone to use the wrapper or capture everything a client does through files, subprocesses or network calls. Runs recorded with reduced directory durability do not receive the full enforced:wrapper classification.

2. Backup and recovery that checks the evidence

A logger should have a recovery path before it has a destructive command.

Chron now takes SQLite snapshots using VACUUM INTO, with a separate manifest describing the snapshot. Restore checks the file digest, database integrity and recorded evidence chains before installing the restored copy. Recovery drills exercise verification without replacing the live database.

Confirmed pruning requires an explicit backup destination and refuses to delete if that backup fails.

Backups and signed exports remain different tools: one restores a database; the other lets someone verify a portable evidence bundle. The backup manifest is unsigned, so its recorded creation time is not independently attested.

3. Reconcile what the client recorded with what Chron holds

chron reconcile compares local Claude Code transcript records with inspected Chron evidence. It is read-only: it does not import, merge or silently upgrade the provenance of a session.

The streaming reader can inspect large transcript files without retaining the whole file in memory. The comparison remains sampled, up to 200 messages per transcript, and reports its inspected scope and limits.

An unmatched record means no correspondence was found within that comparison. It is not proof that someone bypassed logging, and the correspondence fraction is not a capture-completeness score.

4. OpenTelemetry export with delivery receipts

Chron supports operator-initiated OTLP/HTTP JSON trace export for sessions and messages. Conversation content is excluded by default.

The useful part is distinguishing outcomes. A collector refusing an export is not the same as a connection failing before delivery. A request received by a collector that never answers has an uncertain outcome.

chron otel receipts exposes the recorded delivery state rather than flattening those cases into a success tick. This is manual trace export, not automatic telemetry, metrics or log export. A collector response is not proof of permanent retention.

5. HTTP transport defaults that are explicit

For deployments using MCP over HTTP, Chron 0.1.64 requires authentication and binds to loopback by default. It validates Host and Origin, and non-loopback binding requires explicit configuration.

The stdio path remains separate and does not require an HTTP API key.

These are specific controls, not a blanket security claim. Dependency hardening is ongoing and is being scoped separately from feature work.

Verification should explain its boundary

The common thread is keeping the claim close to the evidence.

A journal chain can establish internal consistency; an unanchored chain is not proof that nobody rewrote it. A successful package test does not establish that every AI client will invoke Chron. A local record does not establish that every interaction was captured.

Our latest published-package regression passed 44 release checks and nine streaming checks. Real authenticated client acceptance remains a separate, unfinished test leg, not something those numbers establish.

Chron is available on npm, with source and documentation on GitHub.

For teams using AI developer tools: which gap is hardest today: dependable capture, identifying missing records, or independently verifying the evidence you already have?

Google adds co-creation review flow and three study tools to Gemini Notebook

ColdCaseTech — Sun, 25 Oct 2026 19:58:58 +0000

Originally published on ColdCaseTech.

Disclosure: this post contains affiliate links. We may earn a commission at no extra cost to you.

Then vs. Now (News report): Then: Google announced that Gemini Notebook now offers more creative control over Slide Decks and Video Overviews through a new Review toggle, alongside three recently launched study features. Now: Google stated the co-creation capabilities are rolling out globally to all Gemini Notebook users over the upcoming week.

Google announced on 2026-10-19 that Gemini Notebook now offers more creative control from start to finish on Slide Decks and Video Overviews, including a new Review toggle that lets users examine a plan before anything renders (Google). The company said the co-creation capabilities are rolling out globally to all Gemini Notebook users over the upcoming week (Google). Earlier, on 2026-10-16, Google detailed three study features it had recently launched in the product: Short Video Overviews, Interactive Learning Overviews and expanded quiz formats (Google).

Key Facts

Item	Detail	Source
Product	Gemini Notebook	Google
New control	Review toggle for Slide Decks and Video Overviews	Google
Rollout	Globally to all users over the upcoming week	Google
Study feature	60-second Short Video Overview	Google
Study feature	Interactive Learning Overview under Reports	Google

Timeline

2026-10-16: Google published a post describing three recently launched study features in Gemini Notebook (Google).
2026-10-19: Google announced co-creation capabilities for Slide Decks and Video Overviews in Gemini Notebook (Google).

Details (as Reported)

Google described the co-creation flow as a quick process based directly on the user's sources, replacing a jump from an initial prompt straight to a final output (Google). Users start in the chat and ask Gemini Notebook to create slides or a video overview, and Notebook then suggests topics based on those sources (Google). After the user confirms, the content can be steered further, along with visual style and format (Google).

With the Review toggle on, users can open "Review outline notes" for slides or "Review producer notes" for video in the studio panel (Google). They can add feedback, such as asking for an executive summary at the beginning or swapping the order of a scene, and then select "Proceed" to produce the final artifact (Google). Users who already know what they want can specify it in the prompt and go straight to the review flow (Google). Those who prefer a quick output can skip the toggle and have Notebook generate artifacts as usual (Google).

In its study post, Google said the Short Video Overview is meant to help users unpack a tricky concept and can be shared with a classmate (Google). The Interactive Learning Overview weaves together summaries and studio outputs such as slides, quizzes and flashcards, all grounded strictly in the user's coursework, according to Google (Google). The new quiz formats include short-answer, multi-select and fill-in-the-blank options, and users can ask their notebook for feedback after testing themselves or reviewing flashcards (Google).

Turn text into natural-sounding speech. ElevenLabs generates voiceovers and narration from text, in many voices and languages. Try ElevenLabs (affiliate link)

What Is Not Yet Confirmed

Google stated the co-creation capabilities are rolling out to all Gemini Notebook users globally over the upcoming week, and completion of that rollout has not been reported (Google).

Sources

Tools related to this case

A cheap, disposable Linux box for testing and research: Contabo VPS
Masked email addresses so one leak does not expose your real inbox: Surfshark Alternative ID
Phishing-resistant sign-in for email, cloud and exchange accounts: YubiKey hardware security keys

These are affiliate links: we may earn a commission at no extra cost to you. As an Amazon Associate, ColdCaseTech earns from qualifying purchases.

Live KEV + EPSS data is on the ColdCaseTech Threat Radar - follow us on X (@coldcasetech).

NASA Langley and Virginia Energy sign Space Act Agreement on energy planning data

ColdCaseTech — Sun, 25 Oct 2026 19:58:57 +0000

Originally published on ColdCaseTech.

Disclosure: this post contains affiliate links. We may earn a commission at no extra cost to you.

Then vs. Now (News report): Then: NASA's Langley Research Center announced a new Space Act Agreement with the Virginia Department of Energy to provide solar, meteorological and future weather risk datasets for energy system modeling and planning. Now: NASA said the partnership will bring its POWER data products into Virginia Energy's modeling and analysis system through a digital pipeline to Langley's POWER web platform.

NASA's Langley Research Center in Hampton, Virginia, is partnering with the Virginia Department of Energy to provide solar, meteorological and future weather risk datasets for energy system modeling and planning (NASA). The new Space Act Agreement was announced at a ceremony on Friday (NASA). Under it, the agency will lend its expertise in atmospheric sciences to Virginia Energy's resiliency studies, resource analysis and long-term energy planning (NASA).

Key Facts

Item	Detail	Source
Partners	NASA Langley Research Center and the Virginia Department of Energy	NASA
Agreement type	New Space Act Agreement	NASA
Data provided	Solar, meteorological and future weather risk datasets	NASA
Data source	NASA Prediction of Worldwide Energy Resources (POWER) data products	NASA
Stated purpose	Resiliency studies, resource analysis and long-term energy planning	NASA

Timeline

2026-10-23: NASA published the announcement of the Space Act Agreement between NASA Langley and the Virginia Department of Energy, announced during a ceremony Friday (NASA).

Details (as Reported)

The agreement is meant to help state officials plan for current and potential extreme weather in Virginia and assess what it means for electricity demand, energy generation and system stress (NASA). The information can be incorporated directly into energy policy, planning and operational decisions (NASA).

Relevant data products from POWER, NASA's Prediction of Worldwide Energy Resources, will be infused into Virginia Energy's modeling and analysis system (NASA). POWER supports the design of energy generation systems and the prediction of energy production, using validated data products from NASA's Earth Science to Action program (NASA). Those products represent research and development across Langley, Goddard Space Flight Center in Greenbelt, Maryland, and Ames Research Center in California's Silicon Valley (NASA).

Through a digital pipeline, Virginia Energy can connect to Langley's POWER web platform, download specific datasets and put them directly into its modeling tools (NASA).

"This collaboration with Virginia Energy will benefit the citizens of Virginia and provide stronger energy security for the Commonwealth," said Allen Kilgore, deputy director of NASA Langley (NASA). Vince Maiden, director of Virginia Energy, expects it to "help us better understand how weather affects electricity supply and demand, identify vulnerabilities, and weigh resource tradeoffs with greater confidence" (NASA).

The partnership was fostered through NASA Langley's Strategic Partnerships Office, which connects industry, academia and other government agencies with the center's facilities, capabilities, specialized test environments and technical expertise (NASA).

Protect traffic on networks you do not control. A VPN encrypts your connection on public and shared Wi-Fi, so people on the same network cannot read or tamper with it. See Surfshark VPN (affiliate link)

What Is Not Yet Confirmed

NASA's POWER team members will work with Virginia Energy researchers to streamline the exchange, adjust formats and evaluate the need for additional data (NASA).

Sources

NASA, 2026-10-23

Tools related to this case

Routing optimizer for unstable or high-latency connections: GearUP
AI voice generation for narrating reports, videos and briefings: ElevenLabs
Keeps routers and home servers up through short power cuts: UPS battery backups

These are affiliate links: we may earn a commission at no extra cost to you. As an Amazon Associate, ColdCaseTech earns from qualifying purchases.

Live KEV + EPSS data is on the ColdCaseTech Threat Radar - follow us on X (@coldcasetech).

CX Resolution Agent Blueprint

FDE at Trida AI — Sun, 25 Oct 2026 19:58:22 +0000

Originally published at Trida AI.

A support chatbot is usually graded on how the conversation felt. Did it sound helpful? Was the customer polite at the end? Meanwhile the things that actually cost a telecom operator money and trust sit outside the grade: a credit promised but never applied, a dispute waved through on a story, a customer who asked for a person three times and got a script.

This open blueprint, the CX Resolution Agent, is built around a stricter idea: a support agent should be judged on what it did. Every conversation has one accountable owner. Money moves only on evidence, under written caps. Identity is proven before anything consequential happens. And the moment a conversation should leave the agent, it leaves, by rule rather than by vibes.

One conversation, one owner

A single supervisor owns every conversation from first message to last. Under it sit specialist desks: billing, roaming, plan changes and offers, technical support, account and payments, and a care desk for everything legitimate that falls outside the other five.

The desks never talk to the customer. Each works its part of the problem and hands back findings: what it checked, what it found, what it proposes. Only the supervisor speaks, in one voice, and only the supervisor can put a proposal in front of the customer. That is the choice everything else hangs on: every guarantee the company cares about (figures quoted verbatim, a confirmation actually asked for, policy cited for a policy claim) is enforced in one place instead of hoped for in six.

The desks are deep where a support operation is deep. A troubleshooting walk interrupted by a billing question resumes at the exact step it stopped. If operations already knows about a fault in the customer's area, the agent says so up front, in the operations team's own words, instead of marching the customer through device checks for a problem that was never theirs.

One owner, six desks. The desks return findings; the supervisor alone speaks and answers for the result.

Identity before anything consequential

Explaining a bill is one level of trust. Changing a plan, replacing a payment card, refunding money is another, and the blueprint refuses to blur them.

Before anything consequential can happen, the customer proves who they are: account details first, then a one-time code. Three wrong codes end it. Verification locks, the conversation goes to a person, and no persuasion inside the chat reopens it. An action re-checks everything at the moment it runs: identity still verified, confirmation actually given for this action, policy limits still met by the figures as they now stand. A plan change quoted against Tuesday's balance is not executed against Thursday's; if the account has moved, the proposal is marked stale and re-quoted from live figures, for a fresh yes.

Struggling through verification is itself a signal, so after repeated failed attempts the agent offers a person early. And a returning customer, once verified, is greeted from the record: the complaint still open and the date its response is due, the dispute in flight, the callback booked.

A dispute is decided on the bill

Billing disputes are where support agents quietly bleed money, usually by being agreeable. This blueprint takes the opposite position: a dispute is decided on the evidence carried in the bill itself.

Each disputed line is examined on its own facts. A charge that duplicates another, a charge levied after the account was cancelled, a charge billed above its proper rate: those are evidenced, and they credit, the duplicate in full, the wrong rate for exactly the excess. A line the record clears is declined, with the reason in plain words the customer can argue with. Roaming charges are decided from the account's own history: usage past the fair-use ceiling with no warning ever sent credits; usage inside a pass the customer bought, or after a recorded warning, stands.

All of it runs under written caps. Credits within the cap settle at the desk. A dispute above the cap is neither refused nor forced through; the case escalates to a person with its evidence and reasoning intact. Goodwill runs on a separate, smaller allowance, and the desk reads the account's recent credit history before offering any, so generosity has a memory and a limit. Figures throughout are computed from the record; the model drafts the explanation and never invents a number.

One dispute, traced. The charge is credited for exactly what the evidence on the bill and the account's history supports, no more.

Promises are kept in a ledger

Every support operation makes promises. A response to your complaint by Friday. A technician will call. The instalment lands on the first. Most operations keep those promises in the heads of whoever made them, which is to say they don't keep them.

Here, commitments are written down as they are made and tracked in one ledger: complaint response deadlines, booked callbacks, payment arrangement instalments. Each reads as kept, still pending, or broken, derived from the underlying record and the date, so the ledger cannot drift away from the books it summarises. A broken promise is not buried: it surfaces in the customer's next conversation, and it is listed in full in the daily quality review the operations team reads each morning.

Nothing apologises automatically or pays compensation on its own. A person sees the broken promise and decides what it is worth. The ledger's job is narrower and more valuable: the company can be held to what it said, because what it said is on the record.

Escalation is a rule, not a mood

Ask a support leader when a bot should hand over to a person and you usually get a feeling. This blueprint writes the feeling down as rules, and the rules fire the same way on every channel and at every hour.

Some things transfer immediately: threats, fraud reports, legal matters, a customer whose circumstances mark them as vulnerable. Asking for a human earns one genuine attempt to solve the problem; a second ask transfers at once, with no third pitch. Three turns with no progress transfer. Frustration that keeps rising while nothing lands triggers an early offer of a person before the customer has to demand one. The customer who wants to leave gets the same honesty: one save offer at most, built from real options the account qualifies for, and none if they say they want none.

When a transfer happens, the human does not start from zero. The handoff carries the issue in the customer's own words, what was tried, the figures the case turns on, and what the company still owes them. The packet is checked for completeness and its gaps named on the record, but a transfer is never delayed because the paperwork is imperfect. The customer needs a person; the gap is the team's information, not the customer's wait.

Honest limits

The playbook is finite, and the design would rather admit it than improvise. The desks are deep on the work the operation has defined (bills, faults, plans, roaming, payments, care), and a need outside that definition is logged as unhandled, counted, and shown to the team as a pattern worth designing for, never papered over with a plausible answer. Policy answers cite the policy they rest on; where no policy covers the question, the agent says so.

A few boundaries are deliberate. As shipped, the verification flow demonstrates the steps end to end; a live deployment sends a real one-time code to the customer's phone or email and keeps only proof it matched. Reading free-form customer language well is the connected model's contribution; the built-in fallback assembles replies from findings, and is honest about being a fallback.

Work with us

If your support operation runs on an agent that sounds helpful while credits leak, promises evaporate, and escalations depend on the customer's patience, the fix is structural: one accountable owner, evidence before money, rules before feelings. Start with Trida AI's intake: tell us where your conversations break down.

Get the Code on GitHub: github.com/tridaai/blueprint-cx-resolution

Building an offline-first guard app for Indian housing society gates

gatekeeperzero — Sun, 25 Oct 2026 19:57:59 +0000

A security guard at a housing society gate in India deals with a visitor every few minutes: guests, delivery riders, cabs, house help. The gate is often at the edge of the plot, under a concrete canopy, on a low-cost Android phone with patchy mobile data. If the app stops logging when the network drops, the guard goes back to the paper register, and the society loses its record of who came in.

So when we built the guard app for GateKeeperZero, "keeps working offline" was a hard requirement, not a feature. Here is how it works.

The rule: write locally first, sync later

Every gate action (a visitor check-in, a delivery, a house-help entry) goes through one function: submit directly when online, queue when offline or when the request fails for a temporary reason. The guard sees the same "done" either way. The difference is only where the record waits.

The queue is a small Zustand store, persisted to MMKV so it survives the app being killed. Connectivity comes from @react-native-community/netinfo.

export interface QueuedItem {
  id: string
  type: string            // e.g. 'visitor-checkin', 'delivery-checkout'
  payload: unknown
  idempotency_key: string // generated once, when the guard taps the button
  queuedAt: number
  retryCount: number
  lastAttempt?: number
}

Idempotency keys stop double entries

The hardest bug in offline sync is not losing data. It is duplicating it. A request can reach the server, get saved, and the response can still be lost on the way back. The app thinks it failed and retries.

Each queued item therefore carries an idempotency key created at the moment the guard acted, not at send time. The server keeps each key for 24 hours (the longest an item is allowed to wait offline) and answers a repeat with the original result instead of creating a second entry; the batch response lists the items it saw as duplicates. Retrying becomes safe, so the client can retry freely.

Not every failure deserves a retry

Retries are capped (five attempts), and failures are split in two:

Temporary: no network, timeouts, server errors. The item stays in the queue.
Permanent: the server says the request itself is wrong, or the app version is too old for the API. Retrying won't help, so the item moves to a dead-letter queue and the guard is told it needs attention.

Draining the queue in the background

Guards don't open the app just to sync. A background task (expo-task-manager + expo-background-fetch) drains the queue when the OS wakes the app, and the queue also drains when NetInfo reports the connection is back. Items that map to the same API call go to a batch sync endpoint. A few flows that need two steps (verify a code, then check in) are handled one by one.

Personal data on a shared phone

A gate phone is shared between shifts, so the queue holds visitor names and phone numbers for as short a time as possible:

Dead-letter items auto-expire, and after the first day their payload is stripped down to the type and the failure reason.
Logging out clears the queue. A cancel token stops a drain that is already running from writing the queue back to disk after the clear, which was a real race we had to close.

What we would tell anyone building the same thing

Decide the idempotency strategy before you write the first queue item.
Classify failures early; "retry everything" fills phones with requests that will never succeed.
Treat the on-device queue as personal data, with an expiry and a clear-on-logout path.
Test with the network off at the moment the response is coming back, not just before the request.

If you work on software for Indian housing societies, or just like offline-first problems, we'd like to hear how you handle sync conflicts. More on what the guard app does at the gate: gatekeeperzero.com.

Five States Hold Nearly Two-Thirds of Reported Layoff Workers in Current WARN Data

Layoff Atlas — Sun, 25 Oct 2026 19:57:54 +0000

Five States Hold Nearly Two-Thirds of Reported Layoff Workers in Current WARN Data

Layoff Atlas's current 90-day WARN window contains 704 notices covering 66,156 reported workers, with 33 counts unavailable. Five states — Washington, California, Illinois, Texas and Ohio — account for 42,755 of those workers, or about 65 percent of the total. The other 46 jurisdictions in the registry share the remaining 23,401 reported workers.

That concentration is the single most important thing to understand about the national picture right now. A national total that moves up or down is, in large part, a Washington and California story first, and a five-state story second.

The five states, in order

Washington leads with 17,073 reported workers, about 26 percent of the national total. California follows with 14,224 workers, about 22 percent. Together the two states hold 31,297 workers — roughly 47 percent of all reported workers in the window.

Illinois ranks third with 4,626 workers, about 7 percent. Texas is fourth with 3,652 workers, about 6 percent, and Ohio fifth with 3,180 workers, about 5 percent. The gap between second and third place is striking: California alone has more than three times as many reported workers as Illinois, and Washington has nearly four times as many.

These rankings come from connected sources within the registry, and they describe reported workers in the current 90-day window — not every layoff in the country, and not confirmed job losses. WARN notices are reported plans, not confirmed job losses, and coverage and reporting rules vary by state.

Why concentration happens

A few large filings can move a state's total dramatically. When one filing covers thousands of workers, it can outweigh dozens of small filings elsewhere.

State reporting rules also shape the picture. Some states publish WARN notices promptly and completely; others publish less, later, or not at all in a form the registry can import. A state with a low total may have fewer reported layoffs, weaker public reporting, or both — the registry's figures alone cannot separate those two explanations.

That is why a low number should never be read as "no layoffs." The registry covers 51 jurisdictions, and 48 have imported records. Missing source coverage is not zero layoffs.

What the other 46 jurisdictions look like

Outside the top five, the average jurisdiction accounts for roughly 500 reported workers in the window — but that average hides wide variation. Some states have several thousand reported workers; others have only a handful of notices, or none at all in the current window.

This long tail matters for workers. A 50-worker closure in a small town can be the largest local employer event of the year, even though it barely registers in a national total dominated by five states. National rankings are useful for context, but they are a poor guide to local impact.

The weeks ahead, in the same picture

The concentration in states is mirrored by concentration in time. The registry's upcoming-by-week totals for the six weeks from October 25 are: 5,206 workers in the week of October 25; 4,565 in the week of November 1; 5,311 in the week of November 8; 7,781 in the week of November 15; 6,527 in the week of November 22; and 5,832 in the week of November 29. That six-week total of 35,222 workers is more than half of the entire 90-day window total, and the week of November 15 remains the heaviest week on the calendar.

Read together, the two patterns tell one story: reported layoffs in the current data are concentrated in a few states and in a few coming weeks. A reader watching only the national total would miss both.

How to read these numbers

Three cautions apply to everything in this article. First, these are reported plans, not confirmed job losses — some announced plans are later reduced, postponed or cancelled. Second, 33 notices in the window have unavailable worker counts, so the true total is higher than 66,156 by an unknown amount. Third, the 90-day window rolls forward: as older notices drop out and new ones arrive, totals can fall even in a week when new filings arrive, simply because the window moved.

Dividing 66,156 workers by 704 notices gives roughly 94 workers per notice in headline arithmetic, but that figure is only a rough guide, because the unavailable counts distort it. The more reliable picture is the distribution: a small number of very large filings, a long tail of small ones, and five states holding nearly two-thirds of the total.

For workers in the top five states, the practical message is the same as everywhere else: check whether your employer has filed a notice, note the effective date, and contact your state's Rapid Response team early. For everyone else, the message is not to be reassured by a small state total — check the local filings, because the national ranking says little about your town.

Data source: Layoff Atlas