i onGRC
GitHub↗

John Flack / 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, AI governance, and operational resilience.

Explore the work ↓ LinkedIn↗

Operational layerControl evidenceAccountable decision

IBM iGRC EngineeringFAIROSCALAI GovernanceOperational Resilience

Selected systems

Work that can be inspected,
not merely described.

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

CLAIMS400LEGACY CONTROL LAB01

Can You Prove IBM i Security?

CONTROLPR.AA-05STATUSEVIDENCE DUE

> REVIEW PRIVILEGED PROFILES

> TRACE JOURNAL EVIDENCE

> PACKAGE AUDIT ARTIFACT

> _

F3=Exit   F5=Refresh   F12=Cancel

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.

  • IBM i
  • Control evidence
  • Auditability
  • Docker
Open the lab on GitHub ↗
02IBM 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. The 5250 path remains available as a closed legacy fallback. Not a scanner of record or a live partition connection.

  • IBM i
  • GRC Engineering
  • IBM PSIRT
  • SQL fix evidence
Open the curator ↗
03CYBER-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.

  • FAIR
  • Cyber loss
  • Evidence provenance
Launch INQUISITION ↗
04LIVE DECISION TOOL

IMPACT!

Risk-to-finance modeling engine

Translates cyber and operational risk into financial language—connecting loss exposure, control investment, and decision context in one browser-based model.

  • FAIR
  • Financial modeling
  • CRQ
Launch IMPACT! ↗
05DISCLOSURE WAR ROOM

IMMEDIACY

Every second counts

A disclosure war room for a live ransomware scenario—notice clocks, evidence confidence, stakeholder pressure, and provisional FAIR loss ranges under incomplete facts.

  • Disclosure
  • FAIR
  • Incident decisioning
Launch IMMEDIACY ↗
06DECISION SYSTEM

Decision-Ready

Risk scenario canvas

A structured canvas for moving from ambiguous technical concern to decision-ready risk scenario, with assumptions and accountability kept visible.

  • Risk scenarios
  • Executive translation
Open the canvas ↗
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.

  • OSCAL
  • Policy-as-code
  • Evidence
Inspect the pipeline ↗
08AI GOVERNANCE

AI Fairness Governance Toolkit

From model metric to accountable intervention

A governance-oriented fairness pipeline that frames model evaluation as a documented decision process—not a single score or technical checkbox.

  • Responsible AI
  • Fairness
  • Governance
View the toolkit ↗
09LONG-HORIZON AI

Inheritance

Who inherits the consequences?

An interactive exploration of long-horizon AI decisions, moral uncertainty, and how present choices propagate consequences to future stakeholders.

  • AI safety
  • Values
  • Futures
Launch Inheritance ↗

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.

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 and AI-governance practitioner with deep experience operating business-critical healthcare infrastructure.

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.

Today, I build public tools and learning environments that make those relationships legible—from IBM i evidence at the green screen and Power work queues, to FAIR-informed financial models and AI governance interventions. I also write i on GRC: field notes on what governance looks like from the operational layer, where controls have to produce evidence and risk language has to survive contact with the system.

LinkedIn↗ GitHub↗ GRC Engineering Club Raleigh↗

Open channel

Let’s make the risk
inspectable.

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

Connect on LinkedIn↗