Red Hat AI for Intelligent Tax Administration

Red Hat · Four Inc. · Carahsoft

AI foundations for intelligent tax administration

Rung: data · information · knowledge · judgement

Red Hat · Four Inc. · Carahsoft — Virtual Event · September 17, 2026

What predictive AI, generative AI and LLMs actually do — then how Red Hat turns models, agency knowledge and automation into an operable mission capability, proven in eight labs you run yourself.

Presented by Jon Keam and Brad Scalio.

The ladder as a layered pyramid: 01 Data, 02 Information, 03 Knowledge, 04 Judgement, with the question each layer answers; data informs every layer, the end state is knowing enough to decide, and the rule on the base is to solve a problem someone has

Brad drives, Jon adds color commentary — objective one is to keep the room engaged; entertainment precedes learning. Open by naming the room: Red Hat, Four Inc. and Carahsoft.

The pyramid — the only graphic on this slide, and the spine of the hour. Read it bottom to top. 01 Data, the base and the widest layer: what happened, uninterpreted — returns, transcripts, calls, logs, telemetry. Nothing above it exists without it, and where it lives decides the architecture. 02 Information: data put in context for one case — a score, a classification, a diagnosis. This is what predictive AI and inference produce; a model makes the estimate, a person checks it. 03 Knowledge: information that informs an outcome — guidance, precedent, runbooks — the institution’s memory, retrievable and cited. Generative AI, grounded in approved sources, works here; if it cannot cite, it is not knowledge. 04 Judgement, the apex: a determination a named person signs. Deliberately human — automation executes what was decided and never decides.

Two things the graphic says on its own. The arrow up the side: data informs every layer, so anything higher up the stack has to trace back down to data, or it is decoration. The label at the apex: the end state is knowing — knowing enough to decide, with the evidence in hand.

Why we are here — not to sell a model. Every technology in the hour is tagged with the layer it serves, and every claim gets run in a shell before you leave. The test for anything we show, and for anything a vendor shows you: which layer does it move work up, and which problem in your queue does that solve? Solve a problem someone has; do not invent a solution to one no one has. That rule sits on the base of the pyramid, and if a proposal cannot name the layer and the problem, it is technology looking for a mission.

Say the color code once. It is the rainbow: red on the far left is data — the least structured thing we have; purple on the far right is judgement — the most structured. Every slide carries its colors in the corner, so you always know which rung we are on.

Assume a cold room — about 56 registrants, and most are people we have not worked with. Introduce the three names on the slide in one line each — Red Hat builds the platform, Four Inc. is the federal distributor, Carahsoft is the reseller partner and today’s host — and say why the three of us are here together.

Frame the hour — terminology first so everyone shares a vocabulary, then the platform story, then the labs as the takeaway.

The promise: every claim we make today, we run in a shell before you leave. Security lives in the appendix — pull it up the moment an ISSO engages.

Tell the room: security is at the very end, and it is a broad conversation — anyone who wants to go deeper gets a separate session, and any security question we cannot answer live, we get back to you on.

Four different jobs get called “AI”

Rung: information · knowledge · judgement

Treat AI as a toolbox, not a magic employee. Pick the tool by the job you need done.

Term	What it actually does	Analogy
Predictive AI — estimate (data → information)	Finds patterns in historical data to score, classify or forecast an outcome.	A weather forecast: “there is a 70% chance,” not a guarantee.
Generative AI / LLM — create (information → knowledge)	Produces new language by predicting useful next tokens from patterns learned during training and context supplied now.	A very well-read drafting assistant — fast, fluent, and still capable of being wrong.
Agentic AI — reason + act (knowledge → action)	Pairs a model with approved tools, state and rules so it can plan steps and call systems.	A junior analyst with a badge and a restricted tool belt — permissions still matter.
Automation — execute (executes judgement)	Runs deterministic, tested steps when a condition or human decision says to act.	A checklist that actually performs the checklist. This is where Ansible belongs.

Term

What it actually does

Analogy

Predictive AI — estimate (data → information)

Finds patterns in historical data to score, classify or forecast an outcome.

A weather forecast: “there is a 70% chance,” not a guarantee.

Generative AI / LLM — create (information → knowledge)

Produces new language by predicting useful next tokens from patterns learned during training and context supplied now.

A very well-read drafting assistant — fast, fluent, and still capable of being wrong.

Agentic AI — reason + act (knowledge → action)

Pairs a model with approved tools, state and rules so it can plan steps and call systems.

A junior analyst with a badge and a restricted tool belt — permissions still matter.

Automation — execute (executes judgement)

Runs deterministic, tested steps when a condition or human decision says to act.

A checklist that actually performs the checklist. This is where Ansible belongs.

Predictive AI is not a crystal ball. An LLM is not a database, policy authority or source of truth. An agent is not permission to bypass controls.

Start with the umbrella. Federal audiences hear AI used as if every technique is the same. It is not. Predictive AI estimates or classifies. Generative AI creates. An LLM is a generative model specialized in language. Agentic systems add tools and workflow. Automation executes known steps.

The strongest mission pattern combines them rather than asking one model to do everything.

Land the on-ramp line: if you are not automated, you are not going to have a good generative or predictive AI inside your boundary — automation is the prerequisite.

HAND-OFF (optional): on the Estimate and Create cards Brad turns to Jon — Jon, what do you know about predictive and generative? Give the room an analogy. Jon lands the weather-forecast and well-read-drafting-assistant lines already on the cards; Brad takes back Reason + act and Automate.

The work is seasonal, textual and unforgiving

Rung: data

Demand

Peak load, fixed staff

Idle capacity in August is unjustifiable; exhausted capacity in April is a headline. A year of demand arrives in six weeks — April is 6× the August low.

Systems

Rules locked in legacy code

Rewriting the systems of record is a decade. Wrapping them in intelligent workflows is a quarter.

Data

The answers are in the text

Correspondence, transcripts and case notes are unstructured — exactly what language models are built for.

The constraint that decides everything

The data cannot leave (data — it stays)

FTI handling rules rule out public endpoints. The model comes to the data — on premises, accredited cloud, or air-gapped enclave.

Do not lead with the technology. Lead with the shape of the problem: seasonal demand spikes against a fixed workforce, decades of correspondence logic locked in code nobody wants to touch, and data spread across systems that were never designed to talk.

AI is interesting here precisely because it works on unstructured language — which is most of what a tax agency actually handles.

Context to use with tact: large federal accounts are losing institutional knowledge as people age out or are RIF’d — capturing what the workforce knows is part of why this matters now.

The chart: a year of demand arrives in six weeks. The analogy: Macy’s at Thanksgiving, Black Friday and Christmas — a very seasonal workload against a fixed store. The off-season is not waste; it is when you rewrite and integrate the knowledge you gathered during the surge, so there is more headroom when the next surge comes. Idle capacity in August is only unjustifiable if you do nothing with it.

The closed loop has one rule: it feeds on data from YOUR systems of record, added to your knowledge base to automate it — never information generated from information. That is the snake eating its own tail.

And the constraint that decides the architecture — federal tax information cannot go to a public endpoint; the model comes to the data.

An LLM is the engine — not the whole vehicle

Rung: data · information · knowledge · judgement

Layer	What it is
Mission app (judgement)	The taxpayer-service UI, case workflow or console that asks for help.
Context / RAG (knowledge)	The approved guidance for this exact question — the open book.
Model / LLM (information)	Learned language patterns — not your live system of record.
Inference (data → information)	The engine — vLLM, the Red Hat AI Inference Server.
Platform (executes judgement)	Identity, scaling, isolation, lifecycle, policy — RHEL and OpenShift AI.
Compute + data (data)	Accelerators and agency data — wherever authorization requires.

Layer

What it is

Mission app (judgement)

The taxpayer-service UI, case workflow or console that asks for help.

Context / RAG (knowledge)

The approved guidance for this exact question — the open book.

Model / LLM (information)

Learned language patterns — not your live system of record.

Inference (data → information)

The engine — vLLM, the Red Hat AI Inference Server.

Platform (executes judgement)

Identity, scaling, isolation, lifecycle, policy — RHEL and OpenShift AI.

Compute + data (data)

Accelerators and agency data — wherever authorization requires.

Fine-tuning is studying for the test. Retrieval is bringing the notebook. You want both — and neither makes the model a source of truth.

One central visual, minimal text. This slide has ONE job: show that there is a lot around the LLM, not just the model — the inference runtime, the platform controls and the system around it are what is critical. Do not try to teach every concept here.

Use the car analogy: the LLM is the engine, and an engine alone does not drive you to the store and pick up groceries — you need the vehicle. You want to get from point A to point B — you do not care whether the tires are Goodyear or Kumho; you care that the vehicle does the job and the mission.

Then walk the picture bottom-up: unstructured logs and core dumps at the compute and data layer feed the platform, and the mission app sits at the judgement layer, where a person decides. Running an LLM on a laptop is easy; that is not an enterprise-worthy AI solution.

Then the three knobs, spoken not shown: prompting is better instructions for THIS request; RAG is the right references for THIS request; fine-tuning changes learned behavior for FUTURE requests — durable behavior, never facts that change each filing season.

Land Jon’s analogy on screen: fine-tuning is studying for the test, retrieval is bringing the notebook — an AND, not an either/or, and Red Hat’s own metrics show doing both gives the best results. Brad’s rejoinder if it lands well: some people are bad test takers — that does not mean they did not study.

Tell the room the text stands alone as a takeaway so they stop reading and listen.

From data to judgement — and who climbs each step

Rung: data · information · knowledge · judgement

Every step up is worth more to the mission. AI moves the work up the ladder — it never takes the top step.

Rung	What it is	Looks like	Who climbs to it
Data (data)	What happened, uninterpreted	returns · transcripts · calls · scans	—
Information (information)	Data in context for one case	matched · flagged · routed by intent	Predictive AI — score · match · flag
Knowledge (knowledge)	Information that informs an outcome	guidance · precedent · taxonomies	Generative AI + RAG — read · ground · draft
Judgement (judgement)	A determination someone signs	the decision — and the accountability	People — decide and sign. Stays human.

Rung

What it is

Looks like

Who climbs to it

Data (data)

What happened, uninterpreted

returns · transcripts · calls · scans

—

Information (information)

Data in context for one case

matched · flagged · routed by intent

Predictive AI — score · match · flag

Knowledge (knowledge)

Information that informs an outcome

guidance · precedent · taxonomies

Generative AI + RAG — read · ground · draft

Judgement (judgement)

A determination someone signs

the decision — and the accountability

People — decide and sign. Stays human.

The backlog lives at the bottom of the ladder. Transcribing, matching, routing and summarizing consume the workforce. Every hour a machine absorbs down there is an hour an examiner spends deciding — the only work that resolves a case.

Judgement is deliberately never automated. The model classifies, grounds and drafts; a named person decides and signs. That is a design rule, not a technical limit — and it is what makes the deployment defensible to counsel and oversight.

The masterpiece slide — Jon’s word. Say it out loud — anyone with ten or twenty years in tech will recognize the classic data-information-knowledge-insight progression. We replaced insight with judgement for the AI age, and judgement is the rung that matters most: it is the one a person signs. Walk the stairs left to right: data, information, knowledge, judgement.

Brad’s line, said out loud: we are really good at creating data and information and pretending it is knowledge — if it is not informing anything we need, it is not knowledge. Knowledge has to drive action, not check a box.

Each rung is worth more to the mission. Predictive climbs the first riser, generative with retrieval the second, and judgement is deliberately never automated — that is where people come in and always will.

Make it concrete. Knowledge can be automated: reboot the mail server every Friday, patch the Windows devices every Tuesday — a directive, a mandate or an AO memo turned into a job. Judgement is knowing that a Tuesday when an AWS GovCloud region is down is not the time to run it. AI is not replacing that person; their call feeds back into the loop as the next piece of knowledge.

PLANTED QUESTION: Jon asks ‘so is AI taking jobs?’ — Brad answers: it is not coming for your job, because right now it does not have judgement. The make-the-tests-pass example: ask an AI to make all the tests pass and it edits the code so they pass — it did exactly what you asked. That is information, not knowledge and judgement.

Optional garnish, correctly attributed: Karpathy’s ‘you can outsource intelligence but you cannot outsource understanding.’

Predictive and generative AI answer different questions

Rung: information · knowledge

They fail differently — so they are governed differently.

	Predictive AI (data → information)	Generative AI (information → knowledge)
learns from	Patterns in structured history — filings, payments, outcomes	Language itself — how guidance, notices and case notes are written
produces	A number: a score, a forecast, a flag	Text: a classification, a draft, a summary, a cited answer
in tax terms	Refund-risk scoring · workload forecasting · anomaly flags	Read correspondence · draft notices · summarize case files · answer from guidance
fails as	A bad number — visible in precision and recall	A plausible sentence — which is why grounding and review are non-negotiable
governed by	Back-testing, thresholds, fairness metrics	Retrieval with citations, human sign-off, drift monitoring — Labs 04 · 06

Predictive AI (data → information)

Generative AI (information → knowledge)

learns from

Patterns in structured history — filings, payments, outcomes

Language itself — how guidance, notices and case notes are written

produces

A number: a score, a forecast, a flag

Text: a classification, a draft, a summary, a cited answer

in tax terms

Refund-risk scoring · workload forecasting · anomaly flags

Read correspondence · draft notices · summarize case files · answer from guidance

fails as

A bad number — visible in precision and recall

A plausible sentence — which is why grounding and review are non-negotiable

governed by

Back-testing, thresholds, fairness metrics

Retrieval with citations, human sign-off, drift monitoring — Labs 04 · 06

In the interactive deck this slide is a single graphic: predictive and generative overlap where a score picks the case and a draft explains it, and a person decides.

One graphic, per Jon: predictive and generative overlap. Left crescent, a number from structured history; right crescent, language from text; the lens is where the strongest workflows chain both — score, then explain — and one platform serves both models (Lab 03).

Walk it left to right, then the strip: a score is not a determination, a fluent sentence is not evidence, a person decides. The old six-row table survives in the reveal export and the facilitator guide as the take-home.

Most rooms use one word — AI — for two different tools, and most failed projects picked the wrong one. Predictive models produce a number from structured history; generative models produce language. They fail differently, so they are governed differently.

Close on the compose line: the strongest workflows chain them, and the platform runs both side by side.

OPTIONAL IF TIME IS SHORT — this is a deep dive on the predictive and generative cards from the terminology slide; drop it first and let the table stand as the leave-behind, unless the room asks how the two are governed differently.

Where AI actually lands in the filing lifecycle

Rung: judgement

AI lands on the first four stages, where a reviewer already checks the output; the decision stays with a person; operations close the loop.

#	Station	What happens	Who acts
01	Intake	Capture correspondence from any channel	AI reads it
02	Classification	Understand intent, route to the case type	AI classifies
03	Guidance	Rules, policy and precedent	AI grounds and cites
04	Drafting	Letters, responses, memos, with citations	AI drafts
05	Review	Check accuracy, add judgment, approve	Human in the loop
06	Decision	Finalize and issue the outcome	A person signs
07	Notice	Send letters and update records	Automation executes
08	Operations	Track performance, learn and improve	The loop closes

Station

What happens

Who acts

Intake

Capture correspondence from any channel

AI reads it

Classification

Understand intent, route to the case type

AI classifies

Guidance

Rules, policy and precedent

AI grounds and cites

Drafting

Letters, responses, memos, with citations

AI drafts

Review

Check accuracy, add judgment, approve

Human in the loop

Decision

Finalize and issue the outcome

A person signs

Notice

Send letters and update records

Automation executes

Operations

Track performance, learn and improve

The loop closes

Start where a human already reviews the output (judgement stays human). If a person signs the letter today, a model that drafts it changes throughput without changing accountability. That is a defensible first deployment.
Automate the toil around the model, not just the model (executes judgement). Most of the effort in production AI is provisioning, patching, scaling and evidence collection. That is an automation problem, and it is solved.

Walk the eight stations left to right, the same eight as the graphic (G): AI reads, classifies, grounds and drafts on the first four; a person reviews and signs on five and six; automation sends the notice; operations close the loop. The first four are where language models earn their keep first — high-volume, text-heavy, and a human reviewer is already in the loop, which makes them the honest places to start.

Exam selection is deliberately NOT on this rail (an earlier version of the slide showed it held back): that is a determination affecting a taxpayer and needs a much heavier governance conversation — saying so unprompted buys enormous credibility.

Two rules of thumb: start where a human already reviews the output; and automate the toil around the model, not just the model. Worth naming: most of the effort in production AI is provisioning, patching, scaling and data collection — an automation problem, already solved.

GRAPHIC (G) — Where AI actually lands in the filing lifecycle: An eight- station rail, Intake, Classification, Guidance, Drafting, Review, Decision, Notice and Operations, with five red call-outs over the first five stations; notice that the fifth call-out is a human reviewer and Decision has no call- out at all. Talk to it: (1) Read the rail against the ladder: Intake through Drafting turn data into information and knowledge; Review and Decision are where a person supplies the judgement that stays human. (2) The four AI cards sit where a reviewer already checks the output; neither this graphic nor the slide puts AI on exam selection, because a taxpayer determination needs governance first. (3) Operations closes the loop: what Review corrects and Notice sends goes back into the knowledge base between seasons, and pooled GPUs absorb the 6× April surge on a fixed workforce. (4) One platform under all eight stations: the model comes to the data, the seams stay boring, and controls accredited once for Intake are inherited all the way to Operations.

Five outcomes, and where each one is proven

Rung: data · information · knowledge · judgement

Outcome	Delivered by	Lab
Modernize mission-critical operations (executes judgement) — wrap legacy systems in intelligent workflows instead of rewriting them. An error string in a log fires an Event-Driven Ansible rule, a playbook runs on the right hosts, the on-call gets an email, and a ticket opens and closes in ServiceNow or Remedy. The system of record stays untouched.	Ansible Automation Platform · Event-Driven Ansible · OpenShift	05 · 07
Improve efficiency and accuracy (information, knowledge) — classification, extraction and drafting move first-pass work off people.	Red Hat AI Inference Server · SDG Hub + Training Hub	01–02
Unlock data-driven insights (knowledge) — retrieval grounds every answer in your own published guidance, with the citation returned alongside.	Red Hat OpenShift AI · vector store · Llama Stack	04
Strengthen security and compliance (evidence → judgement) — signed models, FIPS-validated cryptography, continuous compliance scanning and bias/drift monitoring as platform features.	RHEL · Compliance Operator · TrustyAI · Sigstore	06
Build an AI-ready foundation (data → information) — one platform, one operating model, from a datacenter GPU node to an accredited cloud region.	OpenShift AI · KServe · Red Hat AI Inference (vLLM)	03

Outcome

Delivered by

Lab

Modernize mission-critical operations (executes judgement) — wrap legacy systems in intelligent workflows instead of rewriting them. An error string in a log fires an Event-Driven Ansible rule, a playbook runs on the right hosts, the on-call gets an email, and a ticket opens and closes in ServiceNow or Remedy. The system of record stays untouched.

Ansible Automation Platform · Event-Driven Ansible · OpenShift

05 · 07

Improve efficiency and accuracy (information, knowledge) — classification, extraction and drafting move first-pass work off people.

Red Hat AI Inference Server · SDG Hub + Training Hub

01–02

Unlock data-driven insights (knowledge) — retrieval grounds every answer in your own published guidance, with the citation returned alongside.

Red Hat OpenShift AI · vector store · Llama Stack

Strengthen security and compliance (evidence → judgement) — signed models, FIPS-validated cryptography, continuous compliance scanning and bias/drift monitoring as platform features.

RHEL · Compliance Operator · TrustyAI · Sigstore

Build an AI-ready foundation (data → information) — one platform, one operating model, from a datacenter GPU node to an accredited cloud region.

OpenShift AI · KServe · Red Hat AI Inference (vLLM)

These five come straight from the Carahsoft event description, and each one names the product that delivers it and the lab where the audience runs it.

Call outcome 01 the easy first outcome — it needs no AI strategy, only the IT operations automation you already run today: an error string in a log fires an Event-Driven Ansible rule, a playbook runs on the right hosts, an email goes out, a ticket opens and closes in ServiceNow or Remedy.

The point to make: this is how buzzword bingo ties to specific, actual outcomes — things you can start on a laptop today, so you can convince yourself before you try to convince an authorizing official and a CIO.

The lab tags here match the tags Brad already uses in the IRS bi-weekly, so people can find things later. Do not linger — this slide exists so people can map the rest of the hour.

One foundation, from bare metal to the taxpayer

Rung: data · information · knowledge · judgement

Most failures happen at the seams between systems, not inside them. The platform’s job is to make those seams boring.

Layer	What it provides	Lab
Mission applications (judgement)	Correspondence intake · notice drafting · case summarization · guidance assistant. Systems of record stay where they are — reached through APIs and automation, not replaced.	—
Red Hat OpenShift AI	Model serving — KServe + vLLM (information) · Training — SDG Hub · Training Hub (knowledge) · Pipelines — tune · eval · ship (knowledge) · Model registry — signed versions (judgement) · Retrieval — vector store (knowledge)	02 · 03 · 04 · 07
Red Hat OpenShift (data)	Scheduling · GPU partitioning · network policy · multi-site placement · GitOps delivery. The same cluster runs the modernized case-management apps beside the models they call.	—
Red Hat Enterprise Linux · AI Inference Server (data)	Bare metal GPU nodes · virtualized datacenter · accredited public cloud · classified enclave. Granite models, accelerator drivers and the vLLM-based AI Inference Server in one supported stack. Tested with the hardware: mainframes · TPM · PIV/CAC cryptography.	01

Layer

What it provides

Lab

Mission applications (judgement)

Correspondence intake · notice drafting · case summarization · guidance assistant. Systems of record stay where they are — reached through APIs and automation, not replaced.

—

Red Hat OpenShift AI

Model serving — KServe + vLLM (information) · Training — SDG Hub · Training Hub (knowledge) · Pipelines — tune · eval · ship (knowledge) · Model registry — signed versions (judgement) · Retrieval — vector store (knowledge)

02 · 03 · 04 · 07

Red Hat OpenShift (data)

Scheduling · GPU partitioning · network policy · multi-site placement · GitOps delivery. The same cluster runs the modernized case-management apps beside the models they call.

—

Red Hat Enterprise Linux · AI Inference Server (data)

Bare metal GPU nodes · virtualized datacenter · accredited public cloud · classified enclave. Granite models, accelerator drivers and the vLLM-based AI Inference Server in one supported stack. Tested with the hardware: mainframes · TPM · PIV/CAC cryptography.

Two vertical bands run through every layer: Trust (judgement) — signed models, FIPS crypto, SELinux, Compliance Operator, TrustyAI drift + bias, audit trail, air-gap mirroring (Lab 06); and Automation (executes judgement) — Ansible Automation Platform and Event-Driven Ansible: provision, patch, remediate, evidence collection (Lab 05).

Seams riff first (Jon’s request). Failures happen at the seams between systems, not inside. Pants: gain weight and they split at the seams, never where the fabric is strongest. Boring seams is more than fewer: know where each is, operationalize them, have people ready to repair — and do each right, where cyber comes in; the AO’s question, the bridge to the appendix.

Any decision is a lock-in — pizza tonight eliminates spaghetti; Red Hat keeps tomorrow’s spaghetti open. RHEL and OpenShift interoperating layer to layer eases integration — not the only ones, but uniquely placed.

Ansible and OpenShift: heterogeneous platforms, homogeneous interface. Estates are diverse; nobody chose that to spite you. The old system is not legacy to modernize — it joins the same back plane, no snowflakes.

Hardware: mainframes, TPMs, PIV/CAC crypto — it extracts data and creates the information everything above turns into knowledge or judgement; Red Hat tests with vendors so it does what our software expects.

Read bottom to top; the point is the two vertical bands — automation and trust are not a layer added last. Training box: SDG Hub and Training Hub beside serving, pipelines, registry, retrieval.

Naming trap: OpenShift versus OpenShift AI is a product-vs-value tangent — a value room sees serving and retrieval as one (‘I want my data out of it’); split only for a technical room.

Jon’s core: one foundation from bare metal to the taxpayer — but how do you turn information into actionable knowledge?

PLANTED: Jon plays the foil — ‘what’s a seam?’ — Brad answers with the pants; then Brad cold-asks Jon ‘what is fine-tuning to you?’ — Jon is fine with it.

HAND-OFF: after seams and hardware, Brad throws to Jon for the platform boxes — serving, retrieval, registry; Jon closes on why one foundation matters; Brad takes it back: bring the model to the mission, not the data to someone else’s model.

The federal problem is not “get a model.” It is operate AI without giving up control.

Rung: data · information · knowledge · judgement

Bring the model to the mission — not the mission data to somebody else’s model. Use the model, accelerator and deployment location that fit the workload. One operating model across datacenter, accredited cloud, edge and disconnected — and a glass box you can open and inspect, not a black box.

Inference — serve efficiently with vLLM / llm-d · Data — connect private agency knowledge · Agents — govern tool-using workflows · Platform — scale and operate consistently.

	Take-home reference	Why it matters
Choice	Model freedom (knowledge)	Open models and standard APIs keep the exit open. Modern lock-in limits what you can build next — a worse trap than the old hardware kind.
Control	Data locality (data)	Run inference inside the boundary dictated by FTI, mission data, sovereignty and accreditation.
Operations	Models-as-a-Service (information)	Central platform teams publish governed model endpoints other projects consume — instead of every project building its own fragile AI stack.
Economics	Use accelerators efficiently (data)	vLLM and distributed inference focus on throughput, latency and cost per token rather than GPU ownership as a trophy.
Lifecycle	Predictive + generative (information, knowledge)	OpenShift AI manages the lifecycle of traditional ML and generative workloads so they can coexist in one operational model.
Execution	Ansible closes the loop (executes judgement)	Provision, configure, remediate and collect evidence with deterministic automation around probabilistic AI.

Take-home reference

Why it matters

Choice

Model freedom (knowledge)

Open models and standard APIs keep the exit open. Modern lock-in limits what you can build next — a worse trap than the old hardware kind.

Control

Data locality (data)

Run inference inside the boundary dictated by FTI, mission data, sovereignty and accreditation.

Operations

Models-as-a-Service (information)

Central platform teams publish governed model endpoints other projects consume — instead of every project building its own fragile AI stack.

Economics

Use accelerators efficiently (data)

vLLM and distributed inference focus on throughput, latency and cost per token rather than GPU ownership as a trophy.

Lifecycle

Predictive + generative (information, knowledge)

OpenShift AI manages the lifecycle of traditional ML and generative workloads so they can coexist in one operational model.

Execution

Ansible closes the loop (executes judgement)

Provision, configure, remediate and collect evidence with deterministic automation around probabilistic AI.

One focal point: the red box in the middle — bring the model to the mission, not the mission data to somebody else’s model.

Say the two lines: don’t move what’s hard — bring what’s easy to the data. And: what is unique is your data; you have it, you keep visibility into it, and you should never have to give it up. Keep the data on-prem and scale horizontally, or serve the model as a service locally — either way the data does not travel.

Reprise the pizza line once: pizza tonight, spaghetti tomorrow — decisions made today do not limit tomorrow’s alignment to new requirements or technology.

Say the supporting lines rather than pointing at them: cloud AI is ultimately someone else’s computer; on your computer, next to your data, you can go check and verify.

Agencies buy ten thousand chatbot seats and start plugging things in — the alternative they are not shown is running their own instances beside their own data, feeding self-healing closed-loop systems. Colocation cuts attack surface AND transit time.

Automation alone is a differentiator; the estate — one OS, the interconnect, the ecosystem, the execution layer tying them together — is the discriminator nobody else has.

The six cards below are explicitly the take-home reference; tell the room that so they stop reading. The next slide shows the mechanics.

Define the service once — run it wherever the mission needs it

Rung: data · information · judgement

One service definition (executes judgement) — inferenceservice.yaml, a signed model (granite-8b-tax-v1), GitOps delivery from the main branch. Infrastructure as code — the manifest is the capacity plan (Lab 03). oc apply — unchanged: same image · same controls · same skills.

Runs unchanged in		What differs
Datacenter — bare-metal GPU nodes (data)	Your floor, your hardware, shortest path to the systems of record	the iron
Accredited cloud region (data)	FedRAMP boundary; surge capacity rented for the season, released after	the boundary
Air-gapped enclave (data)	Mirrored registry and models; no internet at inference or update time	no internet

Runs unchanged in

What differs

Datacenter — bare-metal GPU nodes (data)

Your floor, your hardware, shortest path to the systems of record

the iron

Accredited cloud region (data)

FedRAMP boundary; surge capacity rented for the season, released after

the boundary

Air-gapped enclave (data)

Mirrored registry and models; no internet at inference or update time

no internet

Accredit once, inherit everywhere (accredit once — judgement). Signing, FIPS mode, compliance scanning and drift monitoring attach to the platform — so workflow two starts with workflow one’s evidence, and the skills and pipelines carry over the same way.
April becomes a scheduling event (information at scale). The 6× filing surge is absorbed by autoscaling on pooled GPUs (Lab 03) — capacity follows the season instead of sitting siloed inside one project’s budget.
Placement is policy, not re-architecture (data — where it lives). Moving a workload is a redeploy of the same manifest. Residency and cost decide where it runs, and the exit door stays open.

The left box is the definition of the service — infrastructure as code: a manifest, a signed model, a GitOps repo. The three on the right are where it runs, unchanged: cloud burst, air-gapped enclave, dev and research. Infrastructure as code decouples the placement so it becomes a policy, not a re-architecture — this is the hybrid multicloud value prop.

The lock-in riff: modern lock-in is far more dangerous than the old kind, because it limits your FUTURE decisions without you even knowing. The Mexico phone-plan analogy — a plan where you cannot call Pizza Hut, only Domino’s. Real lock-in is tying into bespoke hyperscaler-unique services.

Honesty caveat, say it out loud: this is not easy and not right for every situation — sometimes you legitimately need a native service. The ask is only that you define infrastructure and services as code, so placement is policy rather than a rewrite. Fine to spin up fast — then ground it after you prove it.

PLANTED QUESTION: Jon plays the foil — 'what do you actually mean by lock-in? I thought we already bought the software' — and Brad answers with the phone-plan analogy.

The useful pattern is a loop, not a chatbot

Rung: information · knowledge · judgement

Predict, explain, act: spot the pattern, turn the signals into language, use only what the agency has approved. Grounding and learning are how the loop earns the right to act; the connected estate underneath is the discriminator nobody else has.

Step	Technology	What happens
01 · Predict — spot the pattern	Predictive ML (information)	Telemetry and historical incidents estimate risk: saturation, failure probability, anomaly or likely incident class.
02 · Explain — turn signals into language	GenAI / LLM (information)	The LLM summarizes logs, changes and symptoms into a human-readable hypothesis and next questions.
03 · Ground + act — use what the agency approved	RAG (knowledge) · Ansible (executes judgement)	RAG retrieves runbooks and prior fixes; policy decides whether Ansible recommends, requests approval or remediates. Every action opens and closes an ITSM ticket (ServiceNow, Remedy), so the incident record is the trail. Lab 05.
The knowledge flywheel	(knowledge)	After review, the incident summary, root cause, evidence and successful remediation become searchable operations knowledge for the next event. Generated content is a draft until it passes the same curation and authority rules as any other knowledge record.

Step

Technology

What happens

01 · Predict — spot the pattern

Predictive ML (information)

Telemetry and historical incidents estimate risk: saturation, failure probability, anomaly or likely incident class.

02 · Explain — turn signals into language

GenAI / LLM (information)

The LLM summarizes logs, changes and symptoms into a human-readable hypothesis and next questions.

03 · Ground + act — use what the agency approved

RAG (knowledge) · Ansible (executes judgement)

RAG retrieves runbooks and prior fixes; policy decides whether Ansible recommends, requests approval or remediates. Every action opens and closes an ITSM ticket (ServiceNow, Remedy), so the incident record is the trail. Lab 05.

The knowledge flywheel

(knowledge)

After review, the incident summary, root cause, evidence and successful remediation become searchable operations knowledge for the next event. Generated content is a draft until it passes the same curation and authority rules as any other knowledge record.

Example — “Why is this service slow?” Predictive AI says GPU queue depth is abnormal. The LLM explains the evidence. RAG cites the approved saturation runbook. Event-Driven Ansible scales or reroutes after the required approval.

Boundary — do not let fluency become authority. The LLM can propose a root cause. Telemetry, system state, retrieved source material and deterministic checks establish whether that explanation is actually supported.

Segue Brad rehearsed: I talk to my chatbot at night and it tells me how great I am — but you do not want reassurance during a tax audit, a criminal investigation, or a hunt for a pattern. It is not a chatbot. You want something that predicts and explains, then grounds, acts and learns.

Lead with the triad: predict, explain, act. You cannot act unless you have explained, and you cannot explain unless you have predicted. The patterns already exist in your ITSM — P1 through P5 severity and mean-time-to-restore records are what you organize into signals.

Predictive AI flags the risk from telemetry; the LLM explains the evidence; RAG grounds it in approved runbooks; Ansible does only what policy permits, with a human in the loop supplying knowledge and judgement.

At ACT: every action opens and closes a ticket in the ITSM — ServiceNow, Remedy, whatever you run — so you keep track for incident management purposes; that ticket trail is the closed loop system of record.

Caution: do not say agentless or serviceless as an absolute in front of cyber — say no persistent agent, transport is SSH. Ansible is technically not serviceless automation; we speak in general terms, and one SSH-is-a-service objection can derail the loop.

At LEARN: what the loop learns from is data from your own systems — never information generated from information.

Key emphasis: the fluency that becomes authority must be grounded in YOUR language and YOUR processes — not OpenAI’s.

Most of the effort here is provisioning, patching, scaling, data collection and inputs — that is an automation problem, not an AI problem. Automation alone is a differentiator; the estate — one OS, the interconnect, the whole ecosystem with an execution layer tying it together — is the discriminator.

And generated text is a draft until it passes the same curation any knowledge record gets.

Point the same pattern at your logs — MTTR is the proof

Rung: data · information · knowledge

The Lab 04 retrieval stack, aimed at operations: logs, runbooks, incident history and change records become a private notebook the on-call engineer can question — on the cluster, inside the boundary.

Table 1. Where the hours actually live — mean time to resolution, decomposed (representative incident)
	detect	diagnose	fix	total
Before — grep · page · guess	unchanged	2h 41m	22m	3h 16m
With the notebook — ask · verify · act	unchanged	24m	22m	59m

Diagnosis −84%: the notebook answers “what changed, has this happened before, which runbook applies” in seconds, with citations. Detect, fix and verify are unchanged — the hours lived in diagnosis. Lab 07 walks it end to end.

Dashboards answer anticipated questions (information). A notebook over your own data answers the one you did not anticipate — in language, with citations you check before acting.
Logs are FTI-adjacent (data). They carry hostnames, account fragments and case identifiers. The notebook runs on the same OpenShift install it observes — nothing is exported to anyone’s hosted service.
Same stack as the taxpayer system (knowledge). The team that grounds answers for operations (Lab 07) has already built the taxpayer-facing version (Lab 04) — one retrieval pattern, two corpora, one governance story.

The NotebookLM analogy lands instantly: a private notebook that has read everything yours — except this one has read your logs, runbooks, incident history and change records, and it runs on the same cluster it observes. Say resolution, not restoration — mean time to RESOLUTION.

Pair the chart with an outside number, then the personal story — industry numbers for authority, then Brad’s own: an out-of-memory error took us about two hours to diagnose, and it recurred every month because different people were on shift and nothing crossed shifts — so the pattern became every Friday, look for this error message in the log file. AI integration with an LLM on that signal cut diagnosis to 24 minutes and took mean time to resolution from over three hours to under an hour. Say it precisely: 24 minutes is diagnosis, not MTTR.

Second story if there is time, otherwise pick one and say which: the must-gather — the notebook diagnosed in 2 minutes what took the team 46 hours. People love stories.

Then Jon’s requested narration: the big orange bar is diagnosis — that is all information; the blue does not change; what changed is the time to create the information. It ties this chart straight back to the ladder.

Walk the two bars: detection was already fast, the hours lived in diagnosis, and a cited answer to what-changed-and-which-runbook is what removes them. Lab 07 runs this live — offer to jump straight there if the room is operational.

Ninety days, then ninety more

Rung: data · information · knowledge

Crawl, walk, run. Nothing here requires a rewrite of a system of record — ground the current phase before you scale, and each phase produces something you can show.

Prove (data) — crawl · days 0–90	Ground (information) — walk · days 90–180	Scale (knowledge) — run · days 180+
Stand up one supported endpoint with the AI Inference Server	Move serving onto OpenShift AI with autoscaling	Promote through a model registry with real approvals
Agree the accelerator capacity plan and where it physically sits	Add retrieval over your own published guidance	Add workflows two through five on the same platform
Settle which data classes may be used, in writing	Tune on agency vocabulary with SDG Hub + Training Hub	Prove the filing-season surge with a load rehearsal
Pick one text-heavy workflow with a human already reviewing	Wire drift, fairness and compliance monitoring	Extend to the disconnected or classified enclave
Measure the baseline before you change anything	Automate provisioning and patching end to end	Report outcomes in mission terms, not token counts
one workflow live, measured	grounded · monitored · automated	surge-proven at scale

Prove (data) — crawl · days 0–90

Ground (information) — walk · days 90–180

Scale (knowledge) — run · days 180+

Stand up one supported endpoint with the AI Inference Server

Move serving onto OpenShift AI with autoscaling

Promote through a model registry with real approvals

Agree the accelerator capacity plan and where it physically sits

Add retrieval over your own published guidance

Add workflows two through five on the same platform

Settle which data classes may be used, in writing

Tune on agency vocabulary with SDG Hub + Training Hub

Prove the filing-season surge with a load rehearsal

Pick one text-heavy workflow with a human already reviewing

Wire drift, fairness and compliance monitoring

Extend to the disconnected or classified enclave

Measure the baseline before you change anything

Automate provisioning and patching end to end

Report outcomes in mission terms, not token counts

one workflow live, measured

grounded · monitored · automated

surge-proven at scale

Be honest about sequencing. Most agencies fail at AI not on the model but on the second and third bullets of Phase 1 — no GPU capacity plan, and no agreement on which data may be used.

Two riffs to land: plan for problems, not predicaments — the problem right now is grounding the proof so you CAN scale, not the scale itself; no decision today may limit tomorrow’s options. And success means changing your processes, not just moving workloads onto new technology.

Prove, ground, scale maps to data, information, knowledge.

Under Prove: don’t boil the ocean — small pilot, crawl, walk, run. Start with one signal and one use case: the flashback moment when everybody got called in and ruined their Labor Day weekend over something that had happened a hundred times before, but the pattern just wasn’t connected. And you do not start with a ChatGPT-style box; you start with something valuable and integrated with your data and your mission. Ask directly which phase they are in.

PLANTED QUESTION: Jon asks ‘what is a predicament versus a problem?’ — a problem you solve today, a predicament you only plan around.

What happens after this hour

Rung: judgement

Step zero · Lab walk-through. An hour where we run the eight labs together, show and tell, and find the point in the stack where you want to prove value. That scopes the pilot.
Step one · Architecture workshop. A half-day with your platform and security teams to size accelerators, place the first workload and name the data classes in scope.
Step two · Guided pilot. One workflow, on your infrastructure, with a measured baseline and an agreed definition of success before we start.
Step three · Acquisition path. Four Inc. and Carahsoft carry the vehicles and pricing — bring them in early, not at the end.

Point of contact — Brad will follow up. Brad Scalio, Red Hat, bscalio@redhat.com: if nothing else, he will get you to the right person. IRS account executive: Ted Craig, Red Hat. Everyone else, email Brad and he connects you to yours.

Take the labs with you. Everything from today — deck, labs, guides — at https://nommsweymx.github.io/redhat-ai-tax-labs/ (source: github.com/nommsweyMX/redhat-ai-tax-labs). The eight labs are the commands your engineers will run on day one. Follow it on your own: https://nommsweymx.github.io/redhat-ai-tax-labs/adventure.html.

Your move (the next decision is yours).

Already a Red Hat customer? Ask for your Solution Architect. Not sure who that is? Email Brad, open a ticket in the Customer Portal and ask support, or ask through your management line. The foundational questions are free to ask and expensive to skip.
Start a community of practice. A standing group across platform, security and mission teams, built around one workflow. We will help seed it and we will show up.
Bring your hardest question. Air-gapped operation, FedRAMP boundaries, accelerator scarcity, model provenance. If you did not see it here today, that does not mean it does not exist — ask.
Bring your cyber team. If nobody from IRS cyber is on today, refer us to your ISSO or security lead. We will run a dedicated security session for them: the appendix, in depth.

Close with a specific ask, not a thank-you. Step zero, said first: for a PoC we set a time and run the eight labs together — show and tell — to find where in the stack you want to prove value; that scopes the pilot; if it gets serious Brad brings in more people.

Then workshop, guided pilot, acquisition path — engage solution architects early; unanswered foundational questions get reworked later. No stupid questions.

Say the line: not seeing it here does not mean it does not exist or is not a feature or product — name Models-as-a-Service for the platform people.

Point at the contact panel — Brad’s Red Hat email is there deliberately: reach out and, if nothing else, I connect you to the right person, not stick you on somebody else.

Point at Ted — say hi, Ted — Red Hat’s AE for the IRS. Do not know your AE, or not a customer yet? Email me; I connect you with your equivalent of Ted, and pilots route through the AE.

Closer if it fits: that is why we get paid as solution architects — I would rather talk to you than my manager.

Never end with nothing happening after. Then the labs, as the takeaway.

Then the four moves, out loud: already a customer, ask for your Solution Architect — if you do not know who that is, email Brad, open a Customer Portal ticket, or ask up the management line; start a community of practice across platform, security and mission teams; bring your hardest question; bring your cyber team — nobody from IRS cyber today? Refer us to your ISSO or security lead; we run the appendix in depth for them.

Spoken, not on the slide: not IRS or financial services? Reach out anyway — we rebuild this around your mission with your account team.

CLOSING QUESTION, always: anybody on from cyber? Yes — pull up the appendix. No — cyber has had opinions before and deserves a fighting chance to hear it early: can anyone refer us to IRS cyber? We run it for them separately.

Eight labs — real commands, run them yourself

Rung: data · information · knowledge · judgement

An opinionated path on a personal laptop — not an MVP, never production, never on a government computer. Free of charge and open to anyone: one self-contained HTML on the Carahsoft event page, source at https://nommsweymx.github.io/redhat-ai-tax-labs/. Prove it to yourself: watch the model serve on 127.0.0.1.

Lab	Title	What you do
01 · Inference Server	Serve a model inside your boundary (data → information)	Pull the vLLM-based inference server, serve a validated Granite model, and classify a taxpayer inquiry — without a single byte leaving the host.
02 · Customization	Teach it your notice taxonomy (knowledge)	Add agency knowledge as seed YAML, generate synthetic data with SDG Hub, tune with Training Hub, and evaluate against the base model.
03 · OpenShift AI	Survive filing season (information at scale)	Deploy with KServe and vLLM, then watch it autoscale from two replicas to twenty under an April load rehearsal.
04 · Retrieval	Ground answers in your own guidance (knowledge)	Ingest a publication corpus into a vector store and return answers that carry their citation.
05 · Ansible	Automate the toil around the model (executes judgement)	An Event-Driven Ansible rulebook detects inference saturation and remediates it before anyone opens a ticket.
06 · Trust	Prove it to your ISSO (evidence → judgement)	Verify the model signature, check FIPS, run a compliance scan and read drift metrics off live traffic.
07 · Ops notebook	Ask your own logs (information → knowledge)	Ingest logs, runbooks and incident history into an on-cluster notebook, diagnose a live incident with citations — then read the MTTR numbers.
08 · The whole loop	One loop, end to end (data → judgement)	Mainframe and server logs in, an outage-risk model scores who fails next, Lightspeed drafts the rulebook and playbook, a person merges, Event-Driven Ansible runs it, and the assistant answers "how is server8-audits?" with job evidence.

Lab

Title

What you do

01 · Inference Server

Serve a model inside your boundary (data → information)

Pull the vLLM-based inference server, serve a validated Granite model, and classify a taxpayer inquiry — without a single byte leaving the host.

02 · Customization

Teach it your notice taxonomy (knowledge)

Add agency knowledge as seed YAML, generate synthetic data with SDG Hub, tune with Training Hub, and evaluate against the base model.

03 · OpenShift AI

Survive filing season (information at scale)

Deploy with KServe and vLLM, then watch it autoscale from two replicas to twenty under an April load rehearsal.

04 · Retrieval

Ground answers in your own guidance (knowledge)

Ingest a publication corpus into a vector store and return answers that carry their citation.

05 · Ansible

Automate the toil around the model (executes judgement)

An Event-Driven Ansible rulebook detects inference saturation and remediates it before anyone opens a ticket.

06 · Trust

Prove it to your ISSO (evidence → judgement)

Verify the model signature, check FIPS, run a compliance scan and read drift metrics off live traffic.

07 · Ops notebook

Ask your own logs (information → knowledge)

Ingest logs, runbooks and incident history into an on-cluster notebook, diagnose a live incident with citations — then read the MTTR numbers.

08 · The whole loop

One loop, end to end (data → judgement)

Mainframe and server logs in, an outage-risk model scores who fails next, Lightspeed drafts the rulebook and playbook, a person merges, Event-Driven Ansible runs it, and the assistant answers "how is server8-audits?" with job evidence.

One thing to remember: nothing here needed a public endpoint. No public model endpoint, no internet connection at inference time, no rewrite of a system of record. The labs run the upstream bits on a laptop; what an agency accredits is the supported Red Hat product built from them. Lab 08 chains the whole loop.

The concluding takeaway — the deck ends hands-on. Frame it as an opinionated approach: we lead with one path so you do not drown in options.

The line Brad credits, with a hedge, to Danny Mack from the OpenStack days: people hand you the bits and tell you to build something; sometimes you just want the pot to put the plant in. These labs are the pot — the Red Hat opinionated way to get going on a personal laptop, using the upstream community tool chain that is used and secured inside a Red Hat solution.

Say that distinction so nobody leaves thinking the laptop stack is the one that goes in an authorization package: the labs run the community bits on a laptop; the supported Red Hat product built from the same tool chain is what an agency accredits.

Disclaimer, say it: an opinionated path on a personal laptop — not an MVP, never production, and never on a government computer.

Answer the two questions before they are asked: who can take it — anyone; what does it cost — nothing. It is a single self-contained HTML on the Carahsoft event page, with the source in the public repo.

The point is to prove it to YOURSELF — you will watch the model serve on 127.0.0.1 with no egress — because if you do not believe it, an authorizing official will hear that in your voice.

The simulated terminal is the selling point: type each command step by step without installing anything, and off-script commands are refused, which is what makes it a prescriptive, defensible path for a pilot. And the punchline for the AO: your installation and scripting become the artifact you hand them.

The full labs live in the repo — that is where people actually run them, not inside this page.

Close the labs with the offer: if you want us to go deeper on any of these, or run them for a larger audience, reach out — we will do it.

One loop, end to end: from mainframe logs to an assistant that probes

Rung: data · information · knowledge · judgement

Lab 08 · the whole loop. Logs in, risk scored, fix drafted by Lightspeed, merged by a person, run by Event-Driven Ansible, remembered by the platform, so you can ask.

The loop: eight stations, and the eighth feeds the first

Mainframe + servers (data): MVSA · server1..12
Vector · Loki (data): OpenShift Logging
outage-risk scorer (information): KServe · sklearn · OpenShift AI
Granite · Lightspeed (knowledge): vLLM · OpenShift AI
Pull request (judgement): a person reviews and merges
Repo → AAP → EDA (judgement): the merge is the promotion
Event-Driven Ansible (judgement): approved job templates
Knowledge base + assistant (knowledge): pgvector · ops notebook; ask, then probe, and the loop starts again

Table 2. Ask the platform
Question	Answer, with its evidence
How is server1-taxreturns?	Online, up 41d, mem 62%, 72h risk 0.22 and falling; last change CR-9088. [job 40518 · journald · RB-214]
How is server8-audits?	Restored 03:13 by job 40512 (Xmx 7g); risk 0.91 → 0.34; PR #482 merged, INC-2340 closed. [job 40519]
Which servers are showing online?	13 of 14: server1..12 ok, MVSA reachable, MVSB in its IPL window until 06:00. [job 40520 · estate ping]

The loop is the documentation. Every promoted change, its review thread and its job outcome are indexed where the assistant searches. The KM system writes itself.
Two kinds of AI, one platform. The scorer and the drafter share a GPU node, a registry and an identity. Predictive and generative are pods, not projects.
Promotion is a merge. Repo, AAP and knowledge base update together, and a person decides. Nothing runs from a chat window.
Ask, then probe. The assistant’s tools are approved job templates, so "how is server8?" becomes a job with evidence, not a guess.

Lab 08 is the whole hour in one loop; run it if the room is operational, or walk the map.

Read the map clockwise: logs from the mainframe and the servers land in Loki (data); the outage-risk model scores who fails next in the next 72 hours (information); Lightspeed drafts the playbook and the rulebook with citations (knowledge); a person reviews, edits and merges the pull request, and that merge is the promotion into the repo, AAP and the knowledge base (judgement); Event-Driven Ansible runs the approved job when the event fires, 42 seconds, no page; and the assistant answers from what the loop wrote, probing hosts through job templates a person approved.

Say the two takeaways out loud: the platform is also the KM system and the documentation, because every promoted change is a cited record; and the assistant does not change anything, it launches approved jobs and reports with evidence.

Ask the room: what is the last runbook you wrote that the on-call actually found?

HAND-OFF: Jon takes the assistant questions, Brad takes the mainframe row.

The questions an authorizing official will ask

Rung: information · judgement

Evidence is information (information) — the authorizing official’s decision is judgement (judgement). The platform produces the first so a person can make the second.

Their question	The platform control	Where it lives	Proven in
Where does our data go when someone prompts the model?	Nowhere. Inference runs on your cluster, in your enclave, on your accelerators.	AI Inference Server · OpenShift AI	Lab 01 · 127.0.0.1, no egress
Can you prove this model is the one we approved?	Model artifacts are signed and verified before they are admitted to the cluster.	Sigstore / cosign	Lab 06 · cosign verify
Is the cryptography validated?	FIPS mode is set once in RHEL CoreOS and inherited up the chain by OpenShift and OpenShift AI; where a component is not inherited, the exception is documented and covered by compensating controls.	RHEL FIPS mode	Lab 06 · fips-mode-setup, sestatus
Does it work with our smart cards and hardware crypto?	Tested with the hardware vendors: TPM, PIV/CAC smart-card authentication and hardware cryptography supported from the operating system up, on mainframes included.	RHEL · hardware certification	Slide 09 · base band
Can this land in our FISMA moderate or high boundary?	Platform controls map to the NIST 800-53 moderate and high baselines; your FIPS 199 categorization picks the venue — the platform is the same in all of them.	RHEL · OpenShift	Slide 11 · one manifest
How do we know it stays compliant next quarter?	Scheduled scans against a hardening profile, with machine-readable results.	Compliance Operator	Lab 06 · compliancescan
What about the applications and containers we build on it?	The same tooling spans your own application lifecycle on the platform: signing, scanning and admission policy at build, at deploy and at run time.	OpenShift build · registry · admission	Lab 06 · signature gate
How do we detect the model drifting or skewing?	Continuous drift and fairness metrics on live inference traffic.	TrustyAI	Lab 06 · drift, fairness
What if we have no internet at all?	Mirror images and models into the enclave; the platform is built for disconnected operation.	oc-mirror · registry	Slide 11 · enclave
Who is accountable when it is wrong?	A named reviewer on the signature, and every automated action launched from one governed console under enterprise RBAC, so each action carries the identity that ran it.	Workflow design · Ansible Automation Platform	Lab 05 · job history

Their question

The platform control

Where it lives

Proven in

Where does our data go when someone prompts the model?

Nowhere. Inference runs on your cluster, in your enclave, on your accelerators.

AI Inference Server · OpenShift AI

Lab 01 · 127.0.0.1, no egress

Can you prove this model is the one we approved?

Model artifacts are signed and verified before they are admitted to the cluster.

Sigstore / cosign

Lab 06 · cosign verify

Is the cryptography validated?

FIPS mode is set once in RHEL CoreOS and inherited up the chain by OpenShift and OpenShift AI; where a component is not inherited, the exception is documented and covered by compensating controls.

RHEL FIPS mode

Lab 06 · fips-mode-setup, sestatus

Does it work with our smart cards and hardware crypto?

Tested with the hardware vendors: TPM, PIV/CAC smart-card authentication and hardware cryptography supported from the operating system up, on mainframes included.

RHEL · hardware certification

Slide 09 · base band

Can this land in our FISMA moderate or high boundary?

Platform controls map to the NIST 800-53 moderate and high baselines; your FIPS 199 categorization picks the venue — the platform is the same in all of them.

RHEL · OpenShift

Slide 11 · one manifest

How do we know it stays compliant next quarter?

Scheduled scans against a hardening profile, with machine-readable results.

Compliance Operator

Lab 06 · compliancescan

What about the applications and containers we build on it?

The same tooling spans your own application lifecycle on the platform: signing, scanning and admission policy at build, at deploy and at run time.

OpenShift build · registry · admission

Lab 06 · signature gate

How do we detect the model drifting or skewing?

Continuous drift and fairness metrics on live inference traffic.

TrustyAI

Lab 06 · drift, fairness

What if we have no internet at all?

Mirror images and models into the enclave; the platform is built for disconnected operation.

oc-mirror · registry

Slide 11 · enclave

Who is accountable when it is wrong?

A named reviewer on the signature, and every automated action launched from one governed console under enterprise RBAC, so each action carries the identity that ran it.

Workflow design · Ansible Automation Platform

Lab 05 · job history

Open with the labs line: it never leaves your network — true? Prove it to yourself first; if you do not believe it you cannot prove it to an AO. Each row’s Proven-in tag names the lab that proves it: where does our data go? Nowhere; it runs in your enclave.

Appendix by design, for momentum — but this slide unblocks the deal; when an ISSO or security lead engages, pull it up, pick a few rows and drill in, do not read the table.

WHEN CYBER IS IN THE ROOM: seams done right is where cyber comes in. Each layer inherits controls from below — FIPS mode and crypto from RHEL CoreOS carry up through OpenShift and OpenShift AI. No absolutes: what is not FIPS-inherited, say so — documented and addressed elsewhere in the system. Cyber replay: depth here and on seams, no re-pitch.

‘Is AI safe, can we put guardrails on it’ always comes up. Cover: FIPS 199, FISMA moderate or high; federal templating and reporting shipped WITH the platform; air-gap, registry mirroring, Compliance Operator; civilian and DoD share requirements.

FIPS row, credential once: former ITO / ISSO on a FISMA High system — this in your authorization package is perfectly acceptable; practitioner evidence, not a vendor claim.

New rows: hardware crypto — Red Hat tests with vendors (mainframes, TPMs, PIV/CAC) so it does what our software expects; your apps — our security tool chains span their life cycle, not just our products; accountability — every action runs from one governed AAP console, enterprise RBAC, show-back, no islands of automation.

The real difference from commercial is paperwork: attestation, POAMs, FITARA scorecards. Do not roll your own validations — we connect you to a specialist.

If it fits: Hugging Face breach — attackers hit the SaaS model to pivot in; on-prem and SaaS answer different questions.

Brief cyber early: at the IRS ideas die when cyber hears late — hence the community of practice.