Practitioner experience. Applied to new possibilities.
I build risk, compliance, and assurance programs that turn complex requirements into practical decisions. My work spans enterprise governance, control testing, and regulatory readiness—and now, AI-assisted solutions with human accountability built in.
Selected career accomplishments
BillGO / Internal audit
Established the audit methodology, risk-based plan, evidence standards, reporting, remediation validation, and quality program.
~10 audits · ~15 findings
A repeatable assurance capability in a sponsor-bank oversight environment.
BillGO / Enterprise risk
Built the first formal enterprise risk management program: governance, taxonomy, assessments, ownership, monitoring, and executive reporting.
~50 risks · ~6 risk owners
Approximately five assessments, supported by weekly Chief Risk Officer updates.
EarnIn / Compliance assurance
Built risk-based compliance testing and control assurance, including methodology, workpapers, issues management, and remediation validation.
Four-person team · ~10–15 engagements
Approximately 60–70 findings and observations across multiple control domains.
Selected program scope and delivery measures. Findings indicate coverage and identified issues; they are not a measure of realized loss reduction.
Featured project / Elevated GRC
A practitioner-designed workflow to reduce assessment effort, surface supporting evidence, and make consequential judgments easier to review and document.
Explore the review workflow, then inspect the methodology and evidence behind the design.
Draft a risk assessment with source references, the proposed rationale, and questions where support is incomplete.
Intended evidence: incident records, service commitments, and recovery-test results.
The reviewer checks coverage and evidence, adjusts ratings when needed, and documents the reason for the final judgment.
Impact 4 · Likelihood 3 · Control Environment 3
The demo records the revised scores, reviewer rationale, approval state, and session action history.
The broader design adds evidence-linked proposals, attribution, and preserved assessment versions.
Try the review, rationale, approval, and reporting interactions below. AI analysis and integrated evidence handling remain part of the broader platform design.
01 / The opportunity
Organizations pursue opportunities while balancing risk, cost, resources, and expected benefit. Risk assessments provide a structured foundation for those decisions, but the first assessment cycle can demand substantial time from both practitioners and the business.
The design starts with information an organization already has—even when it lacks a mature risk register or control library. Documents, stakeholder accounts, and existing records become inputs to structured analysis, targeted follow-up, and reviewable decisions. Gathering evidence, interviewing stakeholders, evaluating controls, and preparing reporting are all opportunities to reduce avoidable effort.
The development question: How can AI reduce that burden and accelerate assessment work while preserving evidence, professional judgment, and accountability?
02 / Design priorities
The design pairs AI proposals with rationale, source references, missing information, and contradictions. It distinguishes corroborated evidence from management representations and insufficient support, giving reviewers a practical basis for challenge.
People can accept, modify, reject, or investigate recommendations. Material decisions are intended to preserve the original proposal, final judgment, rationale, attribution, and history. Approval responsibility remains with accountable people.
AI assists analysis; deterministic software calculates scores and checks workflow requirements. Methodology, thresholds, and governance triggers are explicit and subject to change control.
What this work demonstrates: the ability to turn experience into a usable operating model, translate it into system requirements, critically review AI-assisted work, and preserve assurance discipline throughout development.
03 / Explore the work
The supplied demonstration contains three synthetic assessments and six risk records. Use this short walkthrough to see how the interactions fit together.
Best explored on a laptop or desktop. Close the demo or press Escape to return here.
04 / A deeper look
These summaries explain the design logic and the boundaries of the current demonstration. Selected standards connections are documented below, with the scope and evidence for each claim.
The intended operating model separates AI proposals from accountable human decisions. Review is meant to be supported by information at the point of decision.
In M022, proposals are seeded examples and decisions are stored only in memory. The broader database records address decision lineage, versioning, and tenant authorization; those controls are not connected to M022. Their documented development checks do not establish production readiness.
Impact and likelihood are each assessed on a five-point scale. Their average determines inherent risk. We then average inherent risk with the Control Environment level to calculate residual risk, subject to the documented cap and no-controls exception.
| Calculation | Method |
|---|---|
| Inherent risk | (Impact + Likelihood) ÷ 2 |
| Residual risk | (Inherent risk + Control Environment level) ÷ 2 |
| Control direction | 1 Highly Effective · 2 Effective · 3 Moderately Effective · 4 Ineffective · 5 Highly Ineffective or Absent |
| Cap and exception | Residual risk cannot exceed inherent risk unless Level 5 explicitly represents no controls in place. |
Worked example: Impact 4 and Likelihood 3 produce 3.50—High inherent risk. Control Environment Level 3 produces 3.25—Moderate residual risk.
Rating bands: Very Low 1.00–1.74; Low 1.75–2.74; Moderate 2.75–3.49; High 3.50–4.49; Very High 4.50–5.00.
The review copy of the demo now follows these calculations and thresholds. Evidence references remain synthetic labels, and scores demonstrate the workflow rather than completed professional conclusions. Rationale is required; its substantive quality is not automatically validated.
Development requirements define scope as a structured record with objectives, boundaries, context, and accountable review. AI may propose scope elements; a practitioner can accept, modify, reject, or investigate them.
The intended design preserves approved scope and handles material changes through a new version or amendment. This illustrates how an assessment practice becomes a data and workflow requirement.
Basis: reviewed Scope Record Requirements specification, September 2026. This is a high-level summary; the internal development record is not included. Scope versioning is not implemented in the M022 standalone demo.
The methodology spans scope and context, requirements, risk identification, impact and likelihood, controls and Control Environment evaluation, residual risk, appetite and tolerance, treatment, approvals, reporting, and reassessment.
AI-assisted evidence review and interview preparation are designed to surface gaps, inconsistencies, and questions that matter to the specific assessment. Interviews remain human-led in the initial operating model.
Reusable risk, control, evidence, and action records support multiple assessment contexts. The design links information to the conclusions it supports, rather than treating an uploaded document as proof of every related assertion.
Basis: methodology and automation assessments, Evidence/Human-in-the-Loop framework, shared platform architecture, and practitioner review through V3. These describe the intended operating model; M022 demonstrates only selected review interactions.
| Decision | Why it matters |
|---|---|
| Evaluate the control environment collectively. | Individual control ratings alone do not establish how controls work together to address a risk. The methodology calls for explicit professional judgment about coverage and effectiveness. |
| Do not automatically reduce risk when an action is completed. | Implementation, validation, and operating effectiveness answer different questions. Action completion is an assertion to evaluate; any revised risk conclusion needs its own basis. |
| Preserve the approved assessment when circumstances change. | Versioned reassessment and comparison preserve what was known and decided at the time. New information should not silently rewrite the historical record. |
These decisions are documented in practitioner reviews and reflected in related database requirements and migration records. They illustrate domain judgment, not measured production outcomes.
The design connects risk conclusions to permitted treatment choices, accountable owners, approval requirements, and follow-up. A tolerance breach triggers evaluation and governance; it does not automatically dictate a single treatment or make every risk unacceptable.
Risk-owner sign-off and additional approvals follow defined responsibilities and triggers. Management action records address completion, independent validation, rejection and rework, cancellation, and carry-forward. Approved baselines and versioned reassessments support a defensible comparison of historical decisions with current conditions.
Basis: treatment/governance rules and M010–M018 development records. Historical test evidence varies by migration and includes retrospective reconstruction; it is not a blanket certification of the complete system.
The documented design maps to selected risk management practices in ISO 31000:2018, NIST SP 800-30 Rev. 1, and COSO ERM 2017. Defined human oversight also relates to selected NIST AI Risk Management Framework 1.0 outcomes.
The mapping connects scope, evidence, risk analysis, treatment, accountable review, reporting, and reassessment to supporting development records. ISO coverage is currently at theme level; NIST tasks and selected COSO principles have more specific references.
The source scoring methodology references NIST SP 800-30, Appendix I. The five-point averaging formulas are a tailored methodology, not formulas prescribed by NIST. Alignment is stated for specific design elements and does not imply certification, endorsement, or complete framework implementation.
Download standards handout · PDF · Download detailed evidence mapping · PDF
Downloads are included with this portfolio. The handout gives a concise overview; the detailed mapping identifies evidence and alignment boundaries.
05 / Evidence & limits
Assessment methods, AI and human responsibilities, evidence expectations, practitioner reviews, and governed workflows establish the intended solution.
Migration records cover evidence relationships, decision lineage, scoring, approval gates, baselines, tenant access, and management actions. Historical test records support bounded development claims.
M022 lets a visitor edit synthetic risk assessments, record a rationale, approve or reopen a decision, and inspect reporting. It is not connected to the database or a live AI service.
| Capability | Current demonstration | Broader platform / remaining work |
|---|---|---|
| Assessment portfolio | Three seeded assessments with displayed progress and owners. | Intake, evidence gathering, and live progress calculation. |
| Risk review | Six synthetic records; search, category filters, editable scores, and rationale. | Evidence ingestion, quality evaluation, and calibrated scoring. |
| AI assistance | Illustrative recommendation labels; no model calls. | Evidence-supported AI analysis and evaluation of recommendation quality. |
| Human approval | Explicit local approval and reopening interactions. | Database requirements and historical records address approval and access controls; integrated application enforcement remains to be validated. |
| Decision history | Session action labels and timestamps. | Broader decision-lineage and version-history records exist; the demo does not expose or exercise them. |
| Management reporting | Counts, priorities, and a rule-based narrative from current demo records. | Validated reporting against real assessment populations. |
The supplied prototype consists of HTML, CSS, and JavaScript. Six view functions render the overview, assessments, risk register, risk review, approvals, and management report.
Interactions update an in-memory state object and recalculate displayed risk scores. There is no database connection, live AI service, persistent storage, or authenticated user session in this demo.
The portfolio embeds that supplied demonstration in an isolated frame. This review copy corrects the supplied demo’s scoring to the source methodology, including scale direction, rating bands, cap, and explicit no-controls exception. Styles and scripts are inlined to make the preview self-contained. The original ZIP is retained separately.
The project records include requirements-to-design traceability, change records, security review, test evidence, technical debt, and release gates. Negative tests examine whether invalid relationships, unauthorized changes, or premature workflow transitions are rejected.
Migration closeouts document specific development scenarios, with some historical evidence reconstructed retrospectively. Later security reviews identify unresolved work, and prepared tests are distinguished from executed results.
This demonstrates an approach to controlled development and transparent evidence. It does not establish that the complete platform is secure, production-ready, or independently certified.
The supplied v0.1.1 release documents a rendering failure caused by incorrect view-dispatch references. The correction points the assessment and risk routes to their view functions.
Package-reported checks: JavaScript syntax, simulated-DOM rendering of all six views, and ZIP integrity. The package explicitly does not claim real Edge end-to-end validation.
Preview preparation checks: ZIP integrity, source syntax, route rendering, rationale validation, score saving, approval, and reopening were checked using a simulated DOM. Portfolio anchor targets and self-contained demo assets were checked programmatically.
Desktop portfolio presentation has been visually reviewed. Comprehensive mobile, accessibility, and end-to-end interaction testing remains outstanding. These checks do not establish production security or readiness.
Further evaluation should compare manual and AI-assisted completion time on equivalent assessment tasks, review evidence support for recommendations, and examine the quality of human corrections.
Useful measures include reviewer effort, unsupported recommendations, material omissions, revision frequency, and decision-record completeness. These are proposed evaluation measures—not results achieved by this prototype.
About Justin
My background spans governance, enterprise risk, compliance, and internal audit across fintech, banking, insurance, healthcare, and technology-enabled operations.
I build practical programs, work across business and technical teams, and turn complex requirements into structured, evidence-based processes. Elevated GRC extends that work into AI-assisted assessment design.
Continue the conversation
I welcome Director, Head, and Senior Manager opportunities in enterprise risk, compliance, and assurance, including roles applying these disciplines to AI governance.
Based in Colorado · Remote opportunities and Denver/Boulder hybrid roles.
Connect with Justin on LinkedIn ↗