Empirical Architecture Mapping & System Legibility

System Cartography & Architectural Proof

Empirical architectural discovery, system mapping, and platform risk governance across high-concurrency production systems.

Staff IC Technical Leadership & Modernization

System Performance & Governance Metrics

Observability
OTel Trace

Reconstructed end-to-end distributed tracing across Acquisition microservices and backends.

Domain Isolation
Decoupled

Unblocked Acquisition engineering streams by establishing explicit service boundaries.

OneMain Financial • 2021: 2026

OneMain Financial: Acquisition Workflow Modernization & Enterprise Telemetry

Role: Associate Director, Staff Engineer | Domain: High-Volume Personal Financial Services

Served as Software Architect for the Acquisition Lane, the customer-facing path through application and account workflows. Mapped the entire loan acquisition and origination pipeline end-to-end from visit to booked loan using the Panoramic View technique of longitudinal and latitudinal analysis across the process sequence, tracing from desktop browser to mainframe and back again at each step, and applied the same depth to the Affiliate API. Identified seven distinct lending funnels through a dedicated tracking initiative, engineered an automated 5-phase PII deletion engine across 30+ tables, and deployed enterprise OpenTelemetry distributed tracing.

Modernization lesson and method

Modernization became possible only after the system became understandable. The work restored reliable signal, mapped actual behavior, and created safer conditions for change across a shared Rails platform.

What was distinctively Mike's: Mike conceived and pitched the cross-functional SME working group strategy to OMF engineering leadership, establishing that platform modernization scales through empowered domain working groups rather than architectural bottlenecks. He recovered lost knowledge and made it actionable, made complex system behavior explainable, connected runtime evidence to squad ownership, and built repeated learning practices that made platform changes safe. Read the evidence.

“Fix what’s broken, upgrade the stuff that works, and stabilize the system to allow change. That is the real path to modernization.”

Mike's method applied here · 2023

Inventory → Evaluate → Address

This is Mike's IEA discovery sequence applied to the Acquisition domain in 2023: establish what exists, decide what is trustworthy and relevant, then take the smallest useful corrective action. Each new pass carries forward what was learned. The six-part modernization sequence is a broader synthesis across IEA, Panoramic View, and OpenTelemetry work.

flowchart LR
  I[Inventory] --> E[Evaluate] --> A[Address]
  1. 01 Inventory Record feature flags, experiments, events, customer journeys, code assets, and the knowledge held by teams. Gate: Can we describe what exists and where the evidence comes from?
  2. 02 Evaluate Test relevance, viability, data quality, knowledge gaps, and the boundary of the Acquisition domain. Gate: Do we know which signals and responsibilities can be trusted?
  3. 03 Address Flatten unnecessary flags, end weak experiments, instrument systems, remove low-confidence events, and cross-train teams. Gate: Did the intervention improve confidence without hiding the remaining uncertainty?

OpenTelemetry modernization framework

Inventory the system before standardizing it

The OpenTelemetry Working Group began with an inventory of what each lane captured, how it captured it, and what each team needed to operate its systems. The goal was a shared Log Data Model and an organization-wide Application Logging Standard that could still accommodate lane-specific constraints.

flowchart LR
  A[Inventory each lane] --> B[Find common and unique data]
  B --> C[Map to one Log Data Model]
  C --> D[Define Application Logging Standard]
  D --> E[Bring in lane representatives]
  E --> F[Instrument and validate]
  F -. learn and refine .-> A
  classDef stage fill:#e6f4f1,stroke:#0f766e,color:#1e232a
  class A,B,C,D,E,F stage
Languages and frameworks

The target was OpenTelemetry compatibility across Ruby, TypeScript, and other systems. That staged path allowed OTel to arrive before a larger framework upgrade.

Infrastructure ownership

Each lane needed a representative who understood its existing logging. The work connected application teams, platform operations, security, and incident response. Ongoing facilitation later moved toward durable operations stewardship.

The active work

  1. 01 Stabilize Restore reliable signal and contain the immediate operational risk. Gate: Can the team make a bounded change without losing the ability to tell what happened?
  2. 02 Understand Map customer journeys, dependencies, ownership, and actual runtime behavior. Gate: Does the evidence connect the business path to code, data, infrastructure, and responsible teams?
  3. 03 Improve Apply targeted fixes, standards, upgrades, and clearer workflows. Gate: Is the intervention small enough to verify and strong enough to reduce the known risk?

What the work makes possible

  1. 04 Measure again Compare the new signal with the baseline and check for unintended effects. Gate: Did the measured behavior improve, remain safe, or reveal a new unknown?
  2. 05 Increase confidence Turn verified results into shared documentation, ownership, and repeatable practice. Gate: Can another team explain the result and operate the system without relying on one expert?
  3. 06 Enable safer change Use the increased confidence to make the next migration, extraction, or upgrade safer. Gate: What is now safe to change next, and what evidence will prove it?

Evidence trail

  • Geekfest@OMF created a recurring forum for shared technical learning beginning November 1, 2022.
  • An Acquisition architecture initiative used Inventory, Evaluate, and Address to improve confidence in customer journeys and event data during 2023.
  • The OpenTelemetry Working Group established a common model for system behavior across heterogeneous platforms during 2024 and 2025.
  • The May 15, 2025 Tech ELT record connects observability, ownership, and modernization.

4-Dimensional Cartography Breakdown

  • Interaction Surface: Mapped the entire loan acquisition and origination pipeline end-to-end from initial visit to booked loan across browser, mobile, and the Affiliate API at identical depth, identifying seven distinct lending funnels through a dedicated tracking initiative.
  • Lateral State Dependencies: Mapped 40+ applicant database tables, isolated legacy clarity_ and underwriting_ orphan data, and architected an automated 5-phase PII deletion engine.
  • Full-Stack Topology: Conducted longitudinal and latitudinal analysis across the process sequence, tracing each step from desktop browser down through Rails services and MuleSoft integration layers to IBM mainframe backends and back again, deploying enterprise OpenTelemetry to establish the unified Enterprise Trace.
  • Supply Chain Exposure: Audited third-party credit bureau APIs, e-sign vendor webhooks, and boundary ingress points, providing real-time causal event chains for cybersecurity and fraud investigations.

Empirical Outcomes

  • Diagnosed and resolved a persistent session-cookie overflow defect affecting 4% of digital applicant traffic by implementing custom rescue middleware and migrating Rails session state to AWS DynamoDB with zero downtime.
  • Engineered an automated 5-phase PII remediation engine across 30+ tables, eliminating legacy orphan references without disrupting live application state.
  • Mapped the entire loan acquisition and origination pipeline end-to-end from visit to booked loan, connecting browser sessions to mainframe transactions via distributed tracing to accelerate root-cause diagnosis for Incident Command.
  • Pitched and executed the enterprise SME working group operating strategy across Acquisition and Platform squads, establishing Geekfest@OMF and the OpenTelemetry Working Group before transitioning ongoing stewardship to SRE.

Phalanx: Duel • 2022: 2026

Phalanx: Duel: Tabletop Rules to Multiplayer Engine

Role: Creator, Principal Architect | Domain: Multiplayer Tactical Game & Engine (phalanxduel.com)

Designed a tactical card duel at Boy Scout Camp Tesomas in 2022 and prototyped its combat rules in Ruby. Rebuilt it as a server-authoritative TypeScript engine, with a deterministic engine package kept separate from the transport layer, a Go CLI, a TypeScript SDK, and an experimental SwiftUI client, now running live at phalanxduel.com.

4-Dimensional Cartography Breakdown

  • Interaction Surface: WebSocket protocol (createMatch, joinMatch, watchMatch, action, authenticate) paired with an OpenAPI 3.0 REST surface for matchmaking, ladder, and replay, a TypeScript SDK, a Go CLI (duel-cli), and an experimental SwiftUI iOS client, all built against one shared schema contract.
  • Lateral State Dependencies: 8-stage turn state machine (StartTurn through EndTurn) enforcing Target Chain, Boundary, and Carryover combat semantics, with Postgres storing match state, action history, and transaction logs as JSONB alongside Glicko-2 Elo snapshots tracked per ladder category.
  • Full-Stack Topology: TypeScript monorepo separating a transport-only server from a deterministic, transport-free engine package, backed by Postgres via Drizzle, Docker-built deploys, Sentry error tracking, and an OTel Collector feeding OTel/LGTM observability across the server and Go client.
  • Supply Chain Exposure: AGPLv3 open-source codebase with 40+ operational wiki and docs guides, an independent combat verifier that checks 2,355,388 declared finite cases and pins a SHA-256 result digest, and CI-gated rule, replay, and playthrough verification ahead of every release.

Empirical Outcomes

  • Built an explainable battle engine that records a versioned, step-by-step combat calculation for every attack, with named operands, ordered operators, and stable PD-RULE identifiers, driving live damage previews, narration, and spectator replay.
  • Verified the combat engine against an independent reference checker covering 2,355,388 declared finite cases, pinning a SHA-256 result digest as a bounded correctness proof.
  • Kept game state synchronized across WebSocket and REST paths for TypeScript, Go, and Swift clients, using role-specific projections and knowledge-safety tests that keep hidden hand and deck information out of what any client can see.
  • Shipped a live production platform (phalanxduel.com) with an automated release pipeline that builds an immutable GHCR container image, promotes it after health and readiness checks, and rolls back to the last known-good image on failure.

The Discovery Method Behind the Studies: IEA & 4D Cartography

In the 2023 Acquisition architecture initiative, I used IEA to turn uncertainty about customer journeys and event data into an actionable record. System Cartography extends that evidence-first practice when reconciling what people think a system does with what it actually does.

Acquisition (ACQ) was the customer-facing path through application and account workflows. The initiative aimed to make ACQ the highest-confidence source for analytics data in OMF by documenting flags, experiments, events, customer journeys, code assets, and team knowledge, then evaluating gaps and addressing them.

flowchart TD
  A[Inventory] --> B[Evaluate]
  B --> C[Address]
  classDef sequence fill:#e6f4f1,stroke:#0f766e,color:#1e232a
  class A,B,C sequence

Outcome: We know where our customers are going. We can make informed decisions. We iterate with confidence. Each new pass starts with what the last pass taught us.

Four questions that make the system legible

The technical names are useful shorthand. These are the questions they answer.

01 // Where does work enter? (interaction surface)

Requests from browsers, mobile clients, APIs, and external consumers.

02 // What else changes? (lateral state dependencies)

Changes crossing domains, queues, transactions, databases, and locks.

03 // What path does it take? (full-stack topology)

The route from the first request through applications, services, infrastructure, and data.

04 // Who else is involved? (supply chain exposure)

External providers, shared dependencies, compliance boundaries, and release checks.