John Flack / Technology risk · Governance engineering

Making technology risk
visible, testable,
and decision-ready.

I build practical systems that connect technical evidence to accountable decisions—across legacy infrastructure, cyber risk, operational resilience, and AI assurance and governance.

IBM iTechnology RiskGRC EngineeringFAIROSCALAI Assurance
20+ yearsEnterprise infrastructure and operations
PlatformsIBM i · AIX · UNIX/Linux
EnvironmentBusiness-critical regulated healthcare
Control realityChange · DR · access · audit evidence

Selected systems

Work that can be inspected,
not merely described.

Each project starts with a governance problem and ends with something usable: a lab, an evidence runtime, a work queue, a decision model, a control pipeline, a research artifact, or an accountable intervention.

01 / FLAGSHIP BUILD

Legacy Control Lab

An IBM i-style governance and security range.

A Docker-based interactive lab that makes legacy-system controls visible to people who have never touched a green screen. Learners investigate access, journaling, evidence quality, and audit readiness inside a realistic CLAIMS400 environment.

Problem Legacy platforms rarely fit modern evidence-engineering examples, even when they remain business-critical.

Built A runnable IBM i-style assurance range with access, journal, privileged-profile, and audit-evidence missions.

Inspect Docker environment · mission flow · evidence paths · public source and documentation.

  • IBM i
  • Control evidence
  • Auditability
  • Docker
Open the lab on GitHub ↗
02LIVE DECISION TOOL

IMPACT!

Cyber risk translated into decisions.

An interactive FAIR-informed decision environment connecting modeled loss exposure, control posture, financial consequence, causal explanation, tail-risk exploration, and executive risk communication across analyst, guided, and board views.

Problem Quantified cyber risk still fails if analysts, executives, and boards cannot see how technical assumptions become business consequences and decisions.

Built A linked decision environment with scenario modeling, TEF/vulnerability-driven loss frequency, deterministic Monte Carlo tail exploration, causal traces, guided walkthroughs, financial analysis, and a board-level risk memo.

Inspect Analyst workspace · tail lens · causal explanation · guided mode · board view · assumptions · public source.

  • FAIR
  • Financial modeling
  • CRQ
  • Decision support
Launch IMPACT! ↗
03CHANGE ASSURANCE RUNTIME

ChangeProof

AI can write the change. Prove it deserves to ship.

A profile-driven software change-assurance runtime that combines source discovery, scoped execution receipts, cross-artifact inference, evidence classification, review compression, and explicit validation boundaries across modern and legacy workloads. Built for the IBM TechXchange 2026 Pre-conference Dev Day Hackathon with IBM Bob 2.0.

Problem A requested change can pass its functional test and still be unsafe to release because related source, configuration, schedules, or target-only validation remain outside the ticket.

Built A reusable evidence pipeline that separates executed, observed, and inferred evidence; preserves release holds when acceptance passes but the evidence chain is incomplete; and demonstrates reuse across both an IBM i-style ORDERPRO workload and an unrelated Node/config workload.

Inspect Live Review Workspace · baseline and post-change evidence packs · machine-readable findings · CI evidence freeze · independent REPORT-GW reuse proof · public source.

Built for the IBM TechXchange 2026 Pre-conference Dev Day Hackathon. ORDERPRO is the primary demonstration workload; the evidence pipeline is the reusable product surface.

  • Evidence engineering
  • Software assurance
  • IBM Bob 2.0
  • IBM i
  • CI/CD
04AI ASSURANCE RESEARCH

ControlSift

Can a small AI model tell proof from paperwork?

Applied AI assurance research testing small-model approaches to cybersecurity control-evidence classification with a hardened synthetic benchmark, classical baselines, Gemma prompting, QLoRA, failure analysis, and explicit research-governance controls.

Problem Relevant documentation can look convincing without proving a control operated, and an AI experiment can look convincing without justifying the claim made from it.

Built A reproducible research stack spanning benchmark generation and leakage hardening, classical baselines, zero- and few-shot Gemma, QLoRA, strict parsing, Failure Lab analysis, Data and Model Cards, a risk register, and a sealed protocol.

Inspect Public research hub · experiment ledger · report · narrated presentation · release artifacts · source.

Developed through Google DeepMind AI Research Foundations via Mentor Me Collective. Within the controlled Gemma v1.0 experiments, few-shot prompting was strongest and QLoRA did not outperform it; the negative result and version boundary are preserved rather than turned into an artificial AI win.

  • AI assurance
  • Model evaluation
  • Control evidence
  • Responsible AI
05CYBER-LOSS CASEBOOK

INQUISITION

Interrogate the loss story

Examines 34 public cyber incidents through cited evidence, source-quality labels, transparent loss assumptions, and bounded FAIR-informed simulation.

Problem Public breach-loss narratives often collapse uncertain facts into false precision.

Built A casebook that keeps sources, evidence quality, assumptions, and quantitative ranges visible together.

Inspect 34 incident cases · citations · source labels · transparent assumptions · bounded simulation.

  • FAIR
  • Cyber loss
  • Evidence provenance
Launch INQUISITION ↗
06IBM i REMEDIATION CURATOR

IBM i Vulnerability Curator

IBM CVE claim → local fix state → reviewable evidence

IBM's CVE_INFO service identifies CVEs affecting a release, but not whether each correcting fix is applied. The curator resolves IBM bulletin remedies, supplies an ACS-ready SQL evidence kit, compares browser-local PTF and Group PTF exports, and packages expected versus observed evidence.

Problem “Release affected” is not the same claim as “correcting fix absent on this system.”

Built Remedy resolution, SQL evidence collection, local export comparison, and reviewer-ready expected-versus-observed output.

Inspect Live curator · public source · SQL evidence kit. Not a scanner of record or live partition connection.

  • IBM i
  • IBM PSIRT
  • SQL evidence
  • Remediation
Open the curator ↗
07CONTROL PIPELINE

GRC Engineering Pipeline

Controls that ship with the system

Terraform, OPA/Rego, OSCAL, signed evidence, and CI/CD enforcement assembled into a verifiable governance pipeline for a regulated workload.

Problem Control evidence is often reconstructed after the fact instead of produced with the system.

Built A policy-as-code assurance chain that preserves passing and failing decisions, signed evidence, and OSCAL-linked control context.

Inspect Terraform · Rego · CI enforcement · signed artifacts · verification paths.

Built through the GRC Engineering Club six-week challenge · 2nd place.

  • OSCAL
  • Policy-as-code
  • Evidence
  • CI/CD
Inspect the pipeline ↗

Operating stance

Governance should leave
a system behind.

Framework fluency matters. The harder work is turning requirements into operating structures that keep producing evidence and better decisions after the workshop ends.

01

Expose the system

Start with how technology actually operates—its identities, dependencies, failure modes, and inherited constraints.

02

Engineer the evidence

Make control performance inspectable and reproducible instead of rebuilding the audit story from screenshots.

03

Translate the decision

Connect technical facts to scenarios, financial exposure, accountability, and the choices leaders must make.

i on GRC / Selected writing

The writing behind
the work.

For more than a year, i on GRC has examined what governance looks like when it reaches the systems, people, evidence, and decisions it is supposed to govern. The subjects change, but the question remains: what survives when framework language meets the operational layer?

Field notes from the operational layer

Operate
Know how the system actually behaves.
Prove
Leave evidence another person can inspect.
Decide
Translate the facts into accountable choices.

About John Flack

Built from the operational layer up.

I’m a technology-risk practitioner with more than two decades in enterprise infrastructure, including business-critical IBM i environments in regulated healthcare.

My work sits where legacy systems, control evidence, resilience, risk quantification, and emerging AI governance meet. Years spent inside systems that organizations depend on—but outsiders rarely understand—shaped a practical view of governance: a control is only as useful as the evidence it produces, and risk language only matters if it improves a real decision.

That operating background includes IBM i, AIX, UNIX/Linux, change governance, disaster recovery, access and privileged-account concerns, audit response, and the day-to-day reality of keeping critical systems supportable. The public work here extends those lessons into evidence engineering, quantitative risk, and accountable governance systems.

Today, I build public tools and learning environments that make those relationships legible, from IBM i evidence at the green screen to FAIR-informed financial models and AI governance interventions. I also publish i on GRC, a long-form practitioner series examining governance from the operational layer.

Open channel

Let’s make the risk
inspectable.

Interested in technology risk, governance engineering, legacy-system assurance, operational resilience, quantitative cyber risk, or accountable AI systems?

Connect on LinkedIn↗