Systems I’ve Built

I don’t just use systems. I build them.

I build reusable systems to organize information, test decisions, check evidence, and improve the work with use.

This is a selective portfolio: only systems developed enough to explain, use, and defend. Some were built for problems that had nothing to do with this site.

System 01

Investment Research & Decision System

The problem

Investment decisions are easy to get wrong when the research is incomplete, the assumptions are weak, or an opinion just sounds convincing.
Doing that research by hand—company financial reports, earnings, stock prices, risks, and the case for and against—takes a lot of time. I want to know whether AI can do much of that legwork without lowering the quality of the decision.
The goal is not to have AI pick stocks for me. It is to research faster, catch things I might miss, have my reasoning challenged, and base the final decision on evidence.

The system

A written rulebook tells the AI how to research and what to check. A separate spreadsheet holds my current investments and numbers, so the rules do not have to be rebuilt every time something changes.
It looks at each investment and at the whole portfolio: Is too much riding on one company? Is the money spread across enough investments? What are the tax effects? Which account should hold what? How quickly could I get cash if I needed it? What else could the money be doing?
Before any recommendation, the AI must check key facts, redo the math, compare other options, and argue against its own conclusion.

What it demonstrates

Investment research
Financial analysis
AI workflow design
Excel
Evidence verification
Analytical reasoning
Risk analysis
Tax-aware decision-making
Systems design
Quality control

Current status

Built and in active use on portfolio decisions. I keep refining it as research exposes missing questions, unnecessary steps, better evidence sources, or stronger ways to test a conclusion.

See it at work: What should I keep, change, or add in my investment portfolio? →

See the system in practice

Example shown with fictional data. The structure, formulas, and design approach are exactly as built.

Company-Level Look-Through: This fictional example shows how owning a company directly and through mutual funds or ETFs can add up. Looking inside the funds reveals ownership that is easy to miss: the four largest companies make up 56.3% of this example portfolio, compared with 52.0% shown by direct stock holdings alone.
Whole-Portfolio Exposure: The fictional whole-portfolio view includes both directly owned investments and holdings inside funds. In this example, 94.6% is in stocks, 86.3% is in U.S. stocks, and technology is the largest industry at 28.5%.
From Analysis to Decisions: The point is not to produce more numbers. This fictional example shows how I use the review to spot overlap, understand each investment’s purpose, and choose what deserves investigation before making any change.

System 02

AI Quality & Recommendation System

The problem

AI can produce polished answers that are incomplete, weakly sourced, inconsistent with controlling decisions, or more confident than the evidence supports. I want a repeatable way to raise the quality bar before I rely on the output.

The system

This is a reusable governing protocol for higher-rigor AI work. It requires the AI to identify the objective and constraints, consult controlling materials, separate facts from assumptions, use the relevant expert lenses, challenge the proposed approach, verify important claims, look for disconfirming evidence, test deliverables when practical, and complete a final quality review before presenting the result.
The goal is not longer answers. It is better-controlled analysis and more reliable output.

What it demonstrates

AI governance
Prompt architecture
Requirements management
Research design
Adversarial review
Quality assurance
Technical communication

Current status

In active use across Engineering My Best Life. I refine it when a recurring failure, ambiguity, or better control becomes visible.

System 03

Cross-Model Review Workflow

The problem

One AI can miss something while sounding confident. For high-value foundation work, I want another independent pass before I rely on the first answer.

The system

This is a review workflow that uses ChatGPT and Claude as separate analytical systems. I do not simply ask both the same question and choose the answer I prefer. I use them to challenge assumptions, identify gaps, test logic, critique implementation, and compare conclusions against the same governing rules and evidence.
Agreement can increase confidence. Disagreement is useful because it shows me where another question needs to be resolved.

What it demonstrates

AI evaluation
Comparative analysis
Workflow design
Validation
Critical thinking
Iterative improvement

Current status

In active use. I am also testing whether one model is stronger overall or whether each is better for specific kinds of work.

System 04

Multi-View Scheduling System

The problem

My wedding schedule contained 262 timed tasks spanning the days around a three-day wedding, with dozens of people and vendors across multiple locations needing different views of the same underlying schedule.
Maintaining a separate schedule for every person, group, day, and location would mean that a single change had to be made in multiple places — and that one missed update could create conflicting versions.
Many changes arrived late, when there was the least time and attention available to update multiple copies carefully.

The system

One master table stores each of the 262 tasks once, including its date, time, description, participants, and the routing information needed to place it in the correct views.
57 generated schedule sheets pull from that master table, creating 58 workbook tabs total including the master.
The same 262 tasks are sliced four ways at once — by person, by group, by day, and by location.
That means a person such as Mother-of-Bride, a group such as Vendors, a day such as Saturday, and a location such as Cousin House can each receive a different view built from the same source data.
Edit the master once, and every affected schedule updates automatically. No generated schedule is maintained by hand.

What it demonstrates

Data modeling
Single source of truth
Excel
Requirements design
Process automation
Stakeholder reporting

Current status

Built in 2024 for my own wedding. It worked as designed: every schedule stayed consistent through every late change.

See the system in practice

Example shown with fictional data. The structure, formulas, and design approach are exactly as built.

58 Total Workbook Tabs: Workbook structure shown here; the master timeline and generated views are detailed below.
The Master Timeline: One master table stores every task once, including the routing information that drives the generated schedules.
Person, Group, and Day Views: The same 262 tasks are sliced into different person, group, and day views from one source. The location view is shown separately.
Location View — Cousin House: Cousin House receives a location-specific view built automatically from the same master data.

System 05

Group Travel Logistics System

The problem

20 travel parties were headed to the same destination on different airlines, arriving at different times, and needing different ground transport.
Each vendor needed different information: the ferry operator needed seat classes and order numbers, the resort needed arrival times and transfer types, and no one needed the full picture.
Payment deadlines, online check-in windows, and dining reservation openings each fell on different dates, and missing one had real consequences.

The system

One master reservation table holds every party's flights, booking references, transfer arrangements, and payment information, with 41 tracked fields per reservation.
Purpose-built views are generated for each vendor, containing only the fields that vendor needs.
A 191-line payment schedule tracks each party's deposits, balances, final-payment dates, and reservation milestones.
Deadlines nobody asked me to track, such as final payment dates, online check-in openings, and dining reservation openings, are recorded alongside the bookings, because the job is making sure nobody misses a deadline they didn't know existed.
Revisions are made in one place and flow to every vendor view, so a flight change never has to be re-entered four times.

What it demonstrates

Logistics coordination
Vendor management
Deadline tracking
Excel
Multi-stakeholder reporting
Payment reconciliation

Current status

Built and used for real client travel in my work as a travel advisor, June 2025–December 2025.

See the system in practice

Example shown with fictional data. The structure, formulas, and design approach are exactly as built.

Master Reservation Table: One Record per Party: Each party's flights, transfers, and payments entered once. A sample of parties and fields is shown; every vendor view is generated from this table.
Payment Schedule: Deadlines Tracked With the Bookings: Deposits, balances, final-payment dates, online check-in windows, and dining reservation openings tracked for every party, so no deadline slips by.
Ferry Operator View: The ferry operator receives only what it needs: order number, lead traveler, party size, seat class, and arrival. No pricing or other vendors' details.
Resort View: Different Fields, Same Source: The resort sees booking references, party size, arrival times, and transfer type, pulled from the same master record as the ferry view.

System 06

Client Intake & Booking System

The problem

Client details were being collected by phone and email and typed up afterward, which put me between the client and the record, and anything transcribed by hand can be heard wrong or spelled wrong.
For international travel, a misspelled name is not a cosmetic error: it has to match the passport exactly, and fixing it later can carry a change fee.
Guests also needed to compare rooms, prices, and transportation options on their own schedule, and answering the same questions individually does not scale across a large group.
Every booking carries deadlines and policies the traveler has to understand before committing, and explaining those one conversation at a time is both slow and inconsistent.

The system

A public trip page presents every room category with photos, inclusions, and approximate cost, so guests compare options on their own time instead of on a call.
A structured intake form captures traveler details at the source, in the format they will be used in, with no transcription step anywhere in the process.
Conditional logic keeps the form short: the number of travelers determines which sections appear, a shared-address answer suppresses a duplicate block, and dietary, mobility, and membership questions each open a follow-up field only when the answer requires one.
Risk controls are built into the flow rather than left to memory: a name-spelling attestation that states the fee for a mismatch, a passport-validity check that prompts renewal early, and explicit acknowledgment of the payment schedule and cancellation policy before submission.
The system absorbs change: when a room category or sailing sold out, the form was updated with the next available option and its price, so it stayed accurate without restarting the process.
A second form handles transportation, branching per traveler so each guest selects their own seat class and add-ons, with a separate acknowledgment from anyone declining protection rather than one blanket waiver.
A live calculated total aggregates every guest’s choices and add-ons and carries into the payment authorization, so nobody agrees to a charge without seeing the figure.
Responses arrive already structured and feed the reservation tracking and vendor views without being handled again.

What it demonstrates

Process design
Requirements gathering
Conditional logic
Data integrity
Risk mitigation
Client communication
Self-service design

Current status

Built and used for real group travel in my work as a travel advisor, June through December 2025. The examples shown here are mockups, rebuilt to show the structure and logic without real client, vendor, or pricing details.

See the system in practice

Example shown with fictional data. The structure, formulas, and design approach are exactly as built.

Room Options Compared Side by Side: Every room category shown with price, bed, view, and outdoor space in the same layout, so guests can compare before selecting.
The Form Adapts to Party Size: Choosing the number of travelers shows a section for each guest, up to three. Clients enter their own legal names and details once, with nothing re-typed.
Risk Controls Built Into Intake: Required acknowledgments before submission: names match travel documents, passports meet validity rules, and payment and cancellation terms are accepted.
Every Guest Decides Separately: Each traveler picks their own seat class and protection, and declining protection requires its own acknowledgment. When a sailing sells out, the form shows the next available one. A live total carries through to payment authorization.