Twitter AI - 2026-09-22¶
1. What People Are Talking About¶
1.1 Model launches were judged on agent economics, not just benchmark peaks 🡕¶
Release-race chatter clearly intensified on 2026-09-22. Roughly 42 tweets mentioned the OpenAI/Anthropic launch cluster versus about 29 the prior day, but the interesting shift was qualitative: people spent less time arguing about a single frontier winner and more time comparing cache-read pricing, task-level cost, rollout surfaces, and where each model actually belongs in a routing table.
@kimmonismus summarized (285 likes, 27 replies, 14,890 views, 35 bookmarks) the day as a split decision: Anthropic's Opus 5.5 allegedly clears Claude Fable 5.1 on Anthropic's headline table while cutting typical Opus 5 costs by about 40%, and OpenAI's GPT-6 Luna posts a 66.6% DeepSWE score at much lower task cost than larger peers while GPT-6 Sol edges closer to Astra on selected coding and automation work. The post mattered because it captured how the feed was reading the launches: not as a clean frontier coronation, but as a routing problem across price, effort level, and workload type.
@aakashgupta argued (22 likes, 2 replies, 3,596 views) that the headline 20% token-price drop understates Opus 5.5's real effect on coding bills, because agentic code work repeatedly re-reads the same files and Anthropic cut cache-read pricing much more aggressively. That gave the economics discussion a concrete operator angle: the useful comparison is not just list price, but how much a long-running coding agent pays to keep context warm.
@CodexReleases reported (30 likes, 2 replies, 576 views) that GPT-6 Sol and Luna were already rolling into Codex and ChatGPT Work, positioning Sol for complex coding and agentic workflows and Luna for focused, high-volume tasks. That rollout detail turned the launch from abstract benchmark news into an immediate tooling change for people already working inside coding-agent surfaces.
@jowettbrendan framed (13 likes, 6 replies, 527 views) Grok 4.7 as the other important part of the economics story: $2 / $6 per million input/output tokens, better numbers than Grok 4.6 on several engineering rows, but still not the clean leader on every benchmark once Fable 5.1 and GPT-6-class systems are included. That made Grok 4.7 relevant less as the uncontested best model than as another serious low-price option in the coding-model mix.
Discussion insight: The strongest correction came from @victornunez, who said (63 likes, 11 replies, 4,068 views) that Sol and Luna should be judged inside a team's own workflows, not by DeepSWE screenshots alone. That matched the broader tone of the day: people were willing to quote benchmark numbers, but reluctant to trust them without live workload evidence.
Comparison to prior day: Compared with 2026-09-21, when the feed was still digesting fresh model announcements and open-weight pressure, 2026-09-22 pushed harder into billing mechanics, rollout surfaces, and task-specific routing choices.
1.2 Agent interfaces became more explicit about fan-out, source targeting, and narrow action surfaces 🡕¶
The second clear theme was implementation specificity. On 2026-09-21, the feed talked about decision layers and verification in principle. On 2026-09-22, people surfaced screenshots and production anecdotes that showed how those systems are actually being wired: source-classification tables, fan-out research tasks, versioned APIs, read-only first deployments, and deliberately narrow write surfaces.
@Charles_SEO argued (44 likes, 4 replies, 6,615 views, 78 bookmarks) that the Opus 5.5 prompt leak was more revealing for operators than many benchmark decks. The key evidence was not just that WebFetch runs on a smaller model, but that Anthropic's example workflow decomposes a CRM comparison into separate assignments for pricing, features, integrations, and user reviews, each with its own sources. That points to a much more criterion-driven search pattern than a single monolithic “research this product” call.
@mardehaym walked through (62 likes, 36 replies, 30,839 views, 47 bookmarks) a brownfield adtech deployment that followed the same logic at the product layer: first build versioned management APIs, separate auth, SDKs, and docs; then expose a read-only MCP service; only after that add narrow write tools like pause, clone, update, and ad-hoc conversion creation. The distinctive point was that the team designed response sizes and summary endpoints for model context limits instead of trying to reuse UI endpoints unchanged.
@JeffreyReitman compressed (4 likes, 3 replies, 114 views) the enterprise lesson into one sentence: AI lands fastest where it does not force users to change the interface, and trust gets built into the workflow rather than added as a separate training exercise later.
Discussion insight: Replies to the adtech thread were some of the day's most practical. One response said, “Everyone wants the MCP. Nobody wants to spend 6 weeks building the boring API foundation that makes it actually work.” That captured the mood exactly: the feed kept rewarding teams that talk about payload shape, permissions, verification, and operational sequencing, not just “AI-enable everything.”
Comparison to prior day: The prior day's conversation drew architectural boundaries between generation, routing, verification, and code. The 2026-09-22 conversation made those boundaries operational with leaked prompt artifacts and explicit brownfield rollout sequences.
1.3 Decision layers got more operational: typed outputs, thresholds, and behavior tests over hype 🡖¶
Jev and related “System One” posts did not disappear, but the volume cooled. Roughly 17 posts hit the Jev/System One cluster on 2026-09-22 versus about 24 the prior day. What survived, though, was denser and more useful: fewer grand claims, more details about cost per case, threshold setting, blind checks, and where these models fail.
@AnatoliKopadze published (18 likes, 4 replies, 1,639 views, 14 bookmarks) a compact Jev playbook that defined the model as a typed decision layer rather than a prose generator. The attached pages matter because they make the contract explicit: your code owns the schema, threshold, and escalation path; the model returns a calibrated answer quickly and cheaply, but not a magic guarantee.
@JustinasRoland0 reported (4 likes, 2 replies, 35 views) running Jev across 520 of his own posts and checking 100 cases against a blinded Fable sample, finding 85/100 agreement on spam and 94/100 on promo while also documenting that Jev was too harsh on short opinion posts and too soft on obvious reply-bait. That kind of failure analysis was more informative than generic “fast and cheap” praise.
@RimShayakhmetov extended (7 likes, 1 reply, 467 views, 5 bookmarks) the pattern into drug discovery, arguing that molecule generation remains the hard part while small models can already handle fast structured judgments. That was one of the clearer signs that the decision-layer idea is trying to escape the coding/content bubble.
@Blue_Beba_ highlighted (28 likes, 10 replies, 336 views, 14 bookmarks) a “Flag Game” preprint where GPT-4o and GPT-5.4 had similar raw accuracy on hidden-flag crops but materially different error patterns and role-dependent performance. The attached graphics made the core point vivid: model behavior is not reducible to one scalar score.
Discussion insight: The Jev/System One thread is no longer “small models never hallucinate.” It is “what schema do you expose, where is your confidence cutoff, what gets escalated, and how do you validate edge cases?” That is a much more mature and much more buildable conversation.
Comparison to prior day: Compared with 2026-09-21's louder Jev evangelism, 2026-09-22 traded volume for concreteness: thresholds, blind checks, vertical use cases, and behavior-difference studies.
1.4 Physical-AI discussion stayed fixed on data engines and ground-truth rails, but with fewer posts than 2026-09-21 🡖¶
Physical-AI/data-engine discussion roughly halved in count from the prior day, but the surviving posts carried harder numbers and clearer product framing. Instead of generic “robots need data” talk, the strongest items argued about capture incentives, dataset growth, and whether one spatial data rail can serve both robotics and world-model training.
@duc_daily described (99 likes, 103 replies, 448 views) the demand-driven mapping thesis behind Vangrid: rather than letting coverage emerge as a side effect of exploration, buyers specify the exact place they want first and payment follows only when that exact place is captured. The point was not that this model is proven, but that it inverts the usual passive-capture economics.
@mr_random14 argued (78 likes, 74 replies, 450 views) that the same ground-level spatial data needed for robotics can also feed world models and broader physical-AI systems. The attached graphic was useful because it made the dual-use argument explicit rather than implied.
@GpaAndy reported (32 likes, 33 replies, 339 views) that Axis Robotics' visible research pool had grown from 207 tasks and 50K+ trajectories to 1,816 tasks and 1.53M verified trajectories in roughly two months. The public AXIS project page adds the operating detail underneath that claim: browser-based MuJoCo-WASM teleoperation in front, and backend validation, smoothing, augmentation, and VLA training behind it.
Discussion insight: Replies kept returning to the same constraint: tasking friction and data quality. One Vangrid reply said the bottleneck is the friction in requesting coverage; Axis replies said the pipeline itself is now the product. In both cases, the pain point sat upstream of the model.
Comparison to prior day: On 2026-09-21, physical-AI discussion was broader and more conceptual. On 2026-09-22, the surviving posts were fewer but sharper: explicit incentive design, verified-trajectory counts, and API-level product surfaces.
2. What Frustrates People¶
Benchmark tables still do not settle routing decisions¶
The sharpest frustration was not lack of benchmark data. It was the opposite: there is now so much release-day benchmark material that people still cannot tell which model belongs in their own stack. @victornunez said (63 likes, 11 replies, 4,068 views) Sol and Luna need a real run in your own workflows because isolated benchmarks only go so far; @morganlinton said (15 likes, 4 replies, 759 views) it is “an expensive time to be an independent benchmarker” while separating routine suites from harder frontier tasks; and even @jowettbrendan framed Grok 4.7 as a model that wins some slices but still trails on overall composite quality. @aakashgupta added (22 likes, 2 replies, 3,596 views) that even simple price comparisons miss the real bill once cache reads dominate agentic coding.
Severity: High. The workaround is to benchmark on real workloads, split “routine” from “hard” task suites, and track task-level cost rather than just leaderboard rank. This still looks worth building for because the evaluation burden itself is becoming a full-time activity.
Brownfield products break when agents are forced through human UI surfaces¶
The second recurring frustration was that many products are still not actually operable by agents. @mardehaym described (62 likes, 36 replies, 30,839 views, 47 bookmarks) teams wiring models to UI endpoints with payloads too large for context, corrupting live configurations on first write, and only later discovering they skipped the underlying API surface. @Charles_SEO showed (44 likes, 4 replies, 6,615 views, 78 bookmarks) that even Anthropic's leaked internal workflow decomposes research into criterion-specific tasks instead of one generic fetch; and @JeffreyReitman argued (4 likes, 3 replies, 114 views) adoption is fastest where the interface barely changes and trust gets built in.
Severity: High. Teams are coping with versioned management APIs, read-only first launches, narrow write tools, and criterion-specific search fan-out, but the feed repeatedly treats these as prerequisites rather than refinements. That makes the gap worth building for.
Decision layers still need calibration, thresholds, and human escalation¶
Jev/System One posts were positive overall, but they were explicit about the remaining failure modes. @AnatoliKopadze said (18 likes, 4 replies, 1,639 views, 14 bookmarks) Jev is typed, calibrated, and fast, but your code still has to own thresholds and escalation; @JustinasRoland0 reported (4 likes, 2 replies, 35 views) that Jev was too harsh on short opinion posts and too soft on obvious reply-bait in his own blind checks; and @RimShayakhmetov argued (7 likes, 1 reply, 467 views, 5 bookmarks) that even in pharma the hard part remains generation, not the fast structured judgment layer.
Severity: Medium. The workaround is stable and sensible—keep the schema tight, route low-confidence cases upward, and validate on domain examples—but that also means there is room for better tooling around calibration, review, and logging.
Physical-world data is still hard to target, verify, and generalize¶
Physical-AI posters kept circling the same upstream bottleneck. @duc_daily said (99 likes, 103 replies, 448 views) demand-driven mapping may target coverage better than passive crowdsourcing but leaves open whether the model scales cleanly; @mr_random14 argued (78 likes, 74 replies, 450 views) world models and robots are now competing for the same real-world data; and @GpaAndy showed (32 likes, 33 replies, 339 views) that even when a data engine grows quickly, quality control and benchmark design become the next problem. Public Vangrid docs also say the spatial API is still early access.
Severity: Medium-High. People are coping with browser teleoperation, verified trajectory pipelines, and early-access spatial APIs, but the feed still treats tasking friction, data quality, and trustable freshness as open problems.
3. What People Wish Existed¶
Workflow-grounded model evaluation that teams can run cheaply and trust¶
The clearest practical need was for evaluation that maps onto real work, not just shared benchmark screenshots. @victornunez wanted teams to judge Sol and Luna on their own workflows; @morganlinton split routine tasks from harder frontier suites; and @aakashgupta focused on the hidden economics of cache reads and multi-step runs. The need is urgent and practical: people want evaluation that reflects their architecture, task mix, latency budget, and cost profile. Opportunity: direct.
Agent-ready APIs with explicit read/write boundaries and smaller payloads¶
What people seemed to want from “agent-ready products” was not a generic AI button. It was an interface designed for the model from the start: narrow summary calls, purpose-built write tools, versioned APIs, and clearly bounded permissions. @mardehaym laid out the sequencing, @Charles_SEO showed the fan-out pattern on the research side, and @JeffreyReitman argued that adoption accelerates when intelligence fits inside the existing workflow. This is a direct product need rather than an aspirational one. Opportunity: direct.
Typed decision layers with thresholds, logs, and domain tuning¶
The Jev/System One cluster points to a more specific wish than “smaller models.” People want a cheap decision layer that can return typed answers with calibrated confidence and cleanly hand off uncertain cases. @AnatoliKopadze made the thresholding model explicit, @JustinasRoland0 showed why domain tuning still matters, and @RimShayakhmetov extended the idea into drug discovery. Some pieces exist already, but the missing layer is better calibration, monitoring, and operator tooling. Opportunity: competitive.
Queryable real-world ground truth for robots and world models¶
Physical-AI posters kept asking for a dependable world-state rail: something that is cheap to collect, current enough to matter, and structured enough to query or stream into downstream systems. @duc_daily highlighted tasking and incentive design, @mr_random14 framed the same data as fuel for both robots and world models, and the public Vangrid API overview shows a query/ingest/stream surface that is still early access. AXIS partly addresses the collection side with browser teleoperation and refinement pipelines, but neither system reads as a finished default. Opportunity: competitive.
Reproducible model snapshots and behavior-diff tooling¶
One quieter but important need came from the Flag Game discussion. @Blue_Beba_ argued that GPT-4o and GPT-5.4 can look similar on accuracy while differing materially in error patterns and role-specific behavior. That creates a need for snapshot retention, behavior regression tests, and tooling that can compare replacements beyond one benchmark number. This is still more of a research and infrastructure need than a mass-market request, but it surfaced clearly enough to watch. Opportunity: aspirational.
4. Tools and Methods in Use¶
| Tool | Category | Sentiment | Strengths | Limitations |
|---|---|---|---|---|
| Claude Opus 5.5 | Frontier model | (+) | Lower typical cost than Opus 5, much cheaper cache reads, faster than Opus 5, strong release-day coding/knowledge narrative | Real workflow wins still need user-side validation, and public discussion was shaped partly by a leaked prompt rather than only clean external evaluation |
| GPT-6 Sol | Frontier model | (+/-) | Positioned for complex coding and agentic workflows, strong cost/performance tradeoff versus larger peers, already rolling into Codex/ChatGPT Work | Public discussion still centered on “test it yourself” rather than obvious universal wins |
| GPT-6 Luna | Efficient coding model | (+) | Designed for high-volume focused work, very low cost in launch comparisons, strong DeepSWE efficiency story | Not presented as the highest-capability option for the hardest tasks; value depends on routing discipline |
| Grok 4.7 | Frontier model | (+/-) | Cheap token prices, better than Grok 4.6 on several rows, credible alternative for some engineering/legal/office workloads | Composite benchmark skepticism remained high, and independent comparisons still favored top OpenAI/Anthropic peers overall |
| Jev / System One | Decision model | (+) | Typed outputs, calibrated probabilities, very low per-case cost, useful for repeated routing/scoring/moderation choices | Needs schema design, thresholds, and escalation logic; can fail on edge cases even when fast and cheap |
| Anthropic WebFetch-style fan-out | Agent research method | (+) | Breaks research into criterion-specific sub-queries, uses smaller models for fetch/parse steps, makes retrieval more auditable | Depends on good task decomposition and source targeting; hard to retrofit into generic “one prompt” products |
| Brownfield agent-enablement API pattern | Integration method | (+) | Starts with versioned management APIs, read-only MCP access, then narrow write tools; aligns payloads to model context limits | Requires weeks of unglamorous foundation work and deliberate product redesign |
| AXIS data engine | Robot data engine | (+) | Browser teleoperation, verified trajectory growth, refinement/augmentation pipeline, visible benchmark snapshots | Data quality, backend curation, and sim-to-reality usefulness remain ongoing burdens |
| Vangrid Enterprise Spatial API | Spatial data API | (+/-) | Query/ingest/stream surface for current world-state data, shared rail for robotics and world-model use cases | Early access, with unresolved trust/latency and market-making questions around collection supply |
| Step Code | Coding harness | (+) | Long-horizon terminal coding, parallel subagents, MCP support, agent skills, token-efficiency focus | Early open-source release with Step provider defaults and meaningful local hardware demands for full-featured use |
Overall sentiment split by workload layer rather than by brand. Frontier launches were praised when they changed the cost of doing real work, not just when they posted a strong number; Jev-style systems were valued because they stripped repeated yes/no decisions away from expensive generators; WebFetch fan-out and brownfield API patterns were discussed as methods more than products; and the physical-AI stack was judged on data collection and verification throughput rather than conversational quality. The operating pattern visible across the feed was explicit routing: cheaper specialized systems for repeated steps, larger models for ambiguous generation, and more structured interfaces everywhere in between.
5. What People Are Building¶
| Project | Who built it | What it does | Problem it solves | Stack | Stage | Links |
|---|---|---|---|---|---|---|
| Velocity Core / Velocity Framework | @mardehaym | Brownfield delivery system that lets isolated agents plan work, run CI, and open PRs inside existing engineering gates | Makes legacy products operable by AI agents without routing them through brittle UI endpoints | Versioned management APIs, dedicated auth, SDKs, Swagger docs, read-only MCP, narrow write tools, webhook-triggered agent runs, CI/PR loop | Alpha | tweet |
| Ming-Image-0.1-Design / Layer | @AntLingAGI | Open-weight UI/UX design model plus a layer-decomposition companion for editable assets | Gives teams a stronger open-source path for design generation and downstream editing | Two 6B models, design generation, layer decomposition, Ling UI Design Skill, Image-to-Editable-PPT Skill | Shipped | tweet, repo, model page |
| Step Code | StepFun | Open-source terminal harness for long-horizon AI coding | Reduces token burn while adding orchestration, delegation, and workflow control around coding models | Step 5 Preview integration, parallel subagents, MCP, Agent Skills, plugin support, /goal, /cron, StepPage publishing |
Shipped | tweet, repo |
| Archify | tt-a1i | Turns repos or plain-language ideas into interactive architecture/workflow/sequence/data-flow diagrams | Helps people understand and share complex systems without hand-drawing diagrams | Standalone HTML output, source-backed tracing, coding-agent integrations, multiple diagram modes | Shipped | repo, site, surfaced in feed |
| Hay.chat | @damien_mulhall | AI customer service software for common support operations | Automates refunds, order tracking, and record updates inside familiar support stacks | Shopify, Zendesk, Stripe integrations, flat SaaS pricing | Shipped | tweet, site, listing |
| AXIS data engine | Axis Robotics | Browser teleoperation pipeline plus growing manipulation-data engine and benchmark | Scales robot-data collection without requiring specialized local setups | MuJoCo-WASM teleoperation, verification, refinement, augmentation, VLA training | Beta | tweet, site |
| Vangrid Enterprise Spatial API | Vangrid | Spatial query, ingestion, and live-stream API for real-world observations | Supplies current world-state data to robotics and world-model systems | Verified 3D spatial data pipeline, REST API, ingestion, live streams | Beta | tweet, API docs |
Velocity Core, Step Code, and Archify all point at the same software-side build pattern: the model is not the product by itself. Velocity Core wraps agents in versioned APIs, CI, PR review, and recovery memory from past failures; Step Code packages similar ideas into an open harness with /goal, /cron, and MCP surfaces; and Archify turns opaque codebases into inspectable architecture artifacts that humans and agents can share.
Ming-Image stood out because it pushes beyond a simple “open image model” launch. The public repo says the release includes one model for high-quality visual design generation and another for decomposing outputs into editable layers, plus agent skills for UI design and image-to-editable slide creation. That is a more workflow-aware design stack than a pure prompt-to-pixels release.
Hay.chat, AXIS, and Vangrid carried the same grounded-operations theme into different verticals: customer support actions, robot-data collection, and current world-state capture. Across all three, the interesting part was not chat quality but verified state and narrow operational leverage.
6. New and Notable¶
OpenAI pushed independent assessment to the top of the day¶
@OpenAI announced (1,676 likes, 309 replies, 176,916 views, 187 bookmarks) that, “as part of our efforts to pace the frontier,” it will support independent assessments with deep access across training, evaluation, and deployment. The corresponding OpenAI post, Priorities and principles for effective third party assessments, is notable because it tries to formalize outside scrutiny as more than a benchmark audit. Replies immediately pushed on the hard part: whether assessors will be able to publish uncomfortable findings and challenge the lab's own assumptions in practice.
Illinois turned AI risk oversight into a standing cabinet-level process¶
@PopCrave reported (79 likes, 14 replies, 10,691 views) that Illinois Governor JB Pritzker launched an AI Cabinet. The official state release, Gov. Pritzker Establishs Illinois Artificial Intelligence (AI) Cabinet, makes the move more substantial than the short tweet alone suggests: the cabinet was created through Executive Order 2026-07, spans agencies and outside experts, and is tasked with incident preparedness, safeguards for public infrastructure, procurement guidance, and data-center/grid-impact questions. That is a sign that AI governance conversation is moving closer to operations.
A 10,000-agent theorem-proving story was used as a lesson in privacy and human review¶
@DeepLearningAI summarized (25 likes, 6 replies, 1,462 views) a controversial result in which 10,000 agents spent 88 hours tackling Navier-Stokes equations in Lean. The notable part was the framing: large-scale multi-agent work can be impressive, but human evaluation is still needed to understand why a proof works, and enterprise-grade privacy / zero-data-retention settings still matter. That kept the research story tied to deployability instead of letting it remain a pure spectacle headline.
7. Where the Opportunities Are¶
[+++] Workflow-grounded evaluation and routing control — The strongest signal across sections 1-4 was that teams still cannot translate release-day benchmark chatter into confident model-routing decisions. @victornunez wanted real workflow testing, @morganlinton split routine from frontier suites, and @aakashgupta showed why cache-read economics can swamp naïve token-price comparisons. This is strong because the demand appeared in user frustration, evaluator work, and major lab messaging on independent assessment.
[+++] Brownfield agent-enablement infrastructure — @mardehaym demonstrated that the real work is versioned APIs, read-only-first access, and narrow write tools; @Charles_SEO showed the matching fan-out pattern on the retrieval side; and projects like Step Code and Archify show builders packaging parts of that substrate. This is strong because the pain is common, concrete, and expensive to solve manually.
[++] Typed decision layers and behavior-regression tooling — Jev/System One evidence stayed positive, but it also made clear that typed answers need thresholds, review loops, and domain tuning. @AnatoliKopadze defined the control pattern, @JustinasRoland0 surfaced real failure modes, and @Blue_Beba_ argued for preserving behaviorally distinct model snapshots. This is moderate because the need is obvious, but buyers may range from product teams to research groups.
[++] Physical-world data rails and verification surfaces — AXIS, Vangrid, and the related discussion all point to the same missing layer: current, queryable, trustable world-state data with tolerable collection cost. @duc_daily focused on demand-led collection, @mr_random14 framed the shared robot/world-model demand, and @GpaAndy showed that once collection scales, validation becomes the next product surface. This is moderate because the pain is real and persistent, but go-to-market and integration complexity remain high.
8. Takeaways¶
- The day's model conversation was about the cost of doing work, not just benchmark peaks. Anthropic, OpenAI, and Grok posts all got traction when they changed the expected bill or routing decision for real coding workloads, especially once cache reads and task-level cost entered the comparison. (source)
- The feed got much more specific about how strong agents actually search and act. The most useful prompt-leak takeaway was not “use tools,” but “fan out the work by criterion, source class, and narrow objective.” (source)
- Brownfield agent adoption still looks like an API and workflow redesign problem. Teams that want production agents need versioned management APIs, read-only launch phases, narrow write tools, and payloads designed for model limits. (source)
- Jev/System One talk is maturing into a practical control-layer pattern. The strongest posts treated these systems as typed, calibrated decision loops with thresholds and escalation paths, not as magical replacements for full LLMs. (source)
- Builder energy is moving into workflow substrate around the model. Step Code, Archify, Ming-Image, and Hay.chat each attacked orchestration, visibility, or downstream editability rather than shipping one more generic assistant wrapper. (source)
- Physical AI still looks more data-engine-constrained than model-constrained. The posts that survived review focused on capture incentives, verified trajectories, browser teleoperation, and queryable spatial feeds—not on novel robot personalities. (source)
- Safety and governance conversation moved closer to operational oversight. OpenAI emphasized deeper third-party assessment access, and Illinois stood up a cabinet-level process around incidents, safeguards, and infrastructure. (source)