Work / Selected systems

Different environments. Same underlying work.

Systems change. The recurring work is to understand the goal, see where reality diverges from the intended experience, and change the appropriate part of the system.

Professional work

The environment changes.
The work transfers.

01 / Litigation Technology & Information Architecture

The capability existed. The usable information system didn’t.

Patterson Buchanan Fobes & Leitch

View case study

Use existing capability

Situation
A litigation technology platform held the needed capability, but legacy records remained difficult to recognize, compare, and retrieve.
Friction
Source identifiers and incomplete contextual metadata preserved provenance, but did not tell people what a record was without opening it.
What changed
Debra developed a repeatable information-architecture method using metadata, retrieval structure, naming, and documentation. Records became more recognizable and findable while source identity remained intact within the existing platform.
What this demonstrates
A new tool is not always the answer. Sometimes the work is building the system that lets people use existing capability effectively.

Completely fictional illustrative example

Before / opaque identifiers

  • ABCXYZ_1234
  • ABCXYZ_4321
  • ABCXYZ_2413

After / recognizable information

  • 2010-01-24 - ABC v XYZ - Complaint
  • 2010-01-24 - ABC v XYZ - Amended Complaint
  • Letter - Smith - Doe - ABC v XYZ - Statement of Representation - 2010-01-24
All names, identifiers, dates, case information, and document examples are completely fictional and created solely to illustrate the information transformation. Any similarity to an actual person, matter, document, or record is purely coincidental. This does not reproduce confidential Patterson Buchanan or Everlaw data.

02 / Platform & Operations

Recurring support demand was a systems signal.

TheCrew Platform

View case study

Build organizational capability

Situation
People with varied technical experience had to move from approval through setup, connection, participation, and ongoing support.
Friction
Recurring setup and connection problems consumed support capacity and kept users dependent on other people to participate.
What changed
Debra combined observation, onboarding, self-service and recovery paths, knowledge, support operations, governance, and distributed leadership. The resulting launcher checked prerequisites, supported installation and recovery, and became a persistent information hub. Connection-related tickets disappeared.
What this demonstrates
Repeated questions and support demand can reveal a system problem, not a series of isolated user problems.
Historical TheCrew launcher home screen showing patch notes, server population and status, play access, community content, and supporting links.
Original historical evidence / launcher and information hub. A surviving launcher artifact brings connection access, service status, patch notes, community content, and supporting resources into one surface.

03 / Product & Systems Development

Build the complete workflow, not just the feature.

Broken Compass Platform

View case study

Build the capability itself

Situation
Broken Compass is a pre-launch multiplayer roleplay platform built in the FiveM environment. Features need to behave believably and remain maintainable within larger product and operational workflows.
Friction
A technically functional feature can still be wrong, confusing, brittle, or expensive to operate when dependencies and edge cases are left outside its scope.
What changed
Debra defines requirements and workflows, uses AI-assisted development alongside direct implementation, tests and refines behavior, and builds the administration, documentation, and governance needed around the capability.
What this demonstrates
Defining the experience and directly building it can remain one continuous act of systems work, including recovery paths, operators, and the people using it.
Broken Compass firefighter using a connected hose to suppress an interior fire, with water and air-supply states visible in the interface.
Current product evidence / implemented workflow. The fire and hose capability is shown in active use with connected water-supply state, resource feedback, and the surrounding multiplayer environment visible.

Independent systems investigations

Investigation before conclusion.

This is a separate evidence class for inquiry conducted without a client or employer mandate. It shows how Debra enters an unfamiliar system, tests explanations, and keeps facts, hypotheses, and unknowns distinct.

01 / Independent Systems Investigation

Status / Research in Progress

Planned output / Findings & Recommendations Report

The outage ended. The investigation didn’t.

Following a prolonged DTE utility outage, Debra independently began investigating regulated infrastructure across prevention, maintenance, restoration, customer information, resilience, and public accountability. The research is ongoing and will conclude with a findings and recommendations report.

Don’t fall in love with the first explanation.

Debra began without professional utility expertise. The investigation records observations, verified facts, questions, hypotheses, inferences, remaining unknowns, and proposed improvements without presenting preliminary explanations as established conclusions.

The outage prompted questions about which controls and dependencies existed upstream and downstream of the incident, how they performed, and what the available evidence can establish about possible causes and responsibility.

Systems in view

  • Vegetation risk
  • Detection and remediation responsibility
  • Response
  • Restoration information
  • Resilience
  • Accountability
  • Accessibility