What We Build

The work on this page reflects what I actually produce — not proposals or concepts, but functioning systems built to address real problems in specific domains. Each project began with close observation, direct conversation, or a genuine question worth pursuing. Each one was designed from first principles, built with attention to industry standards and best practices, and delivered as something that actually runs.

I bring 17 years of experience working inside federal government systems — including Federal Student Aid, the Office of Medicare Hearings and Appeals, and the Consumer Financial Protection Bureau, where I conducted examinations of depository and non-depository institutions across industries to determine whether their systems were in compliance with consumer protection laws. That work gave me a firsthand view of how institutional systems are actually built — and what drives the decisions behind them. Too often, those decisions are shaped by political or capitalistic ideology rather than operational integrity or the people the systems are meant to serve. I build differently. I research best practices. I align with industry standards. I keep politics out of the architecture.

What I bring to this work:

  • Systems thinking — designing architectures that hold together under real conditions, not just in theory
  • Domain translation — taking a clinical practice, a contemplative tradition, or a market problem and rendering it accurately in software without losing its original meaning
  • AI integration — real agent design with memory, tools, and reasoning chains — not prompt engineering as a novelty
  • Full stack execution — frontend, backend, infrastructure, deployment, and documentation — the whole thing
  • Research discipline — investigating best practices before building, not after
  • Conceptual originality — the ideas are mine, not derivatives of tutorials or someone else’s roadmap

Domain Tools & Clinical Workflow

Systems built around specific professional practices — designed through direct observation of how a practitioner actually works, not around how a generic application assumes they do.

Five Element Acupuncture Session Tracker

Built after five years of observing a practicing acupuncturist’s clinical workflow firsthand, this prototype maps her methodology — how she takes a patient from the moment they walk through the door to the moment they leave. What you see in it reflects her framework, her approach, and her sequence of practice. It is not a clinically validated system. It is a proof of concept — built to show what becomes possible when a developer observes closely enough to translate a practitioner’s way of working into software. The next step is an expert refining what I started.

View Prototype →

Contemplative Practice Tools

AI-powered tools designed for contemplative and spiritual practice — built around specific traditions with care for their integrity, not as wellness abstractions.

Sadhana Guide Agent

Most wellness apps assume you already know what you’re doing. This one doesn’t. I built the Sadhana Guide Agent for complete beginners — people who want to start a contemplative practice but don’t know where to begin. It asks how you feel, learns your patterns over time, and recommends a practice drawn from Vedic, Buddhist, Zen, and Tantric lineages without overwhelming you. Under the hood it runs on Node.js, TypeScript, LangChain, and Claude — hosted on dedicated infrastructure in Helsinki. The technical architecture and the philosophical orientation were both deliberate choices. This is not a wrapper around someone else’s app. It is an original system built on original thinking.

View Prototype →

Proprietary Products

Market-facing tools conceived, designed, and built independently — standalone products addressing problems identified through research and direct experience.

Passage

Modern travel generates a documentation problem that no existing tool has solved. Airline confirmations, rental car pickups, hotel check-ins, and Airbnb access instructions arrive as separate emails from separate vendors — each formatted differently, each burying the operational details a traveler actually needs inside marketing copy and legal disclaimers. The result is a passenger standing in a terminal, jet-lagged, pulling up four different email threads trying to find the one sentence that tells them what to do next.

Passage solves this. It accepts raw confirmation documents — PDFs, pasted email text, or both simultaneously — and converts them into a precise, chronological, step-by-step operational itinerary. Not a summary. Not a list of bookings. A sequence of discrete, actionable instructions extracted verbatim from the confirmation language itself — exact door numbers, exact phone numbers, exact shuttle islands, exact keypad codes — presented as a color-coded timeline grouped by day. The itinerary can be printed or saved as a self-contained HTML file for offline access on any device, with no app required.

Built in a single day. Deployed the same day. The insight that drove it was not technical — it was human: anxiety in travel comes from not knowing what to do next. Passage eliminates that entirely.

View Live App →

FORGESIGNAL

I was curious about whether I could build a tool that analyzes public GitHub repositories and determines whether the raw material inside them could produce something of consequence. FORGESIGNAL is what that curiosity produced. It reads any public repository — its code, documentation, configuration files, data, and notebooks — and renders a verdict: GO, PASS, or REVISIT. It produces a consequence score, a competitive landscape, build angles across every scale and monetization model, risk factors, and a single concrete next action. It runs on React, Vite, and Claude, deployed on Vercel with a serverless API relay. The idea, the architecture, the design, and the deployment were completed in a single working session.

View Live App →

Integration Consulting

Documented walkthroughs and integration work — helping people understand and implement the tools their projects need, step by step, in plain language.

Clerk Authentication — Guided Integration Walkthrough

Beyond building my own systems, I work as an integration consultant — helping people understand and implement the tools their projects need. This project demonstrates that side of my work. It walks a complete beginner through integrating Clerk, a professional authentication and user management platform, into a Next.js web application. Every step is documented in plain language with real terminal output. If you want to build this yourself, the repository is a safe sandbox where you can practice the entire integration before applying it to your own project. You are welcome to use it.

View Live App →    View Repository →

Consumer Financial Rights

A catalog of tools built on federal examination standards — designed to put the regulatory knowledge that institutions have always had directly into the hands of the consumers those institutions are supposed to serve. Each tool in this catalog is grounded in publicly available federal examination procedures. None of it is legal advice. All of it is education.

Know What You Signed — Auto Loan Optional Products

When you finance or lease a vehicle, optional products — GAP insurance, extended warranties, credit life insurance, credit disability insurance, tire and wheel protection — are rolled into your loan at origination, folded quietly into your monthly payment inside a stack of documents you sign at the Finance and Insurance desk. Most consumers never know what they bought. Many never know they may be owed a refund when their loan pays off early or a product expires unused. The people who sold those products have no financial incentive to tell them.

I built this system in two parts. The first is an Apify Actor — a cloud-based knowledge extraction engine — that scrapes and parses four federal sources: the CFPB Automobile Finance Examination Procedures webpage, the 2024 Supervisory Highlights Auto Finance Special Edition webpage, the full 45-page examination procedures PDF, and the full 22-page supervisory highlights PDF. It then passes targeted sections of that content to Claude with a constrained extraction prompt — no interpretation, no legal opinion, factual extraction only — and structures the output into a clean, queryable dataset following UCI Machine Learning Repository documentation standards. Each row represents one optional product and contains its plain language definition, product category, authorization requirements, disclosure requirements, refund eligibility status, refund trigger conditions sourced directly from 2024 examiner findings, and the exact checkpoint questions federal examiners ask when they walk into a dealership or lender.

The second part is the consumer-facing application — built in React and Vite, styled with Playfair Display and DM Mono typography, animated with CSS keyframes, and deployed to a custom subdomain via Vercel. It reads the structured dataset and presents it in plain language: what each product is, whether you may be owed a refund, what authorization was required before it could be added to your loan, and what federal examiners specifically check for when evaluating whether that authorization was obtained. The knowledge base is grounded in the same documents federal examiners carry into the field. The delivery mechanism is plain language. The intended beneficiary is the consumer.

This is the first tool in the Consumer Financial Rights Catalog — a planned series of Actors and applications covering credit cards, mortgage origination, debt collection, education loans, and short-term lending. Each one follows the same architecture: federal examination procedures as the knowledge foundation, a Claude extraction layer constrained to factual output, a structured dataset consumable by any developer via API, and a consumer-facing interface built on top of it. The Actor will be published to Apify Store for developer rental when the catalog reaches critical mass. This is not a one-off tool. It is the first release of a system.

This is not legal advice. This is education. The gap between what consumers sign and what consumers understand has been profitable for long enough.

Know What You Signed →

Credit Card Rights Navigator

Most credit card holders have no idea what federal law required their issuer to disclose before charging them a fee, enrolling them in an add-on product, or changing their interest rate. That information exists — it lives inside the CFPB Credit Card Account Management Examination Procedures, a document federal examiners use in the field. It has never been made accessible to the people it was written to protect.

This tool changes that. The consumer selects the situation they are facing — an unexplained fee, a charge they want to dispute, a product they don’t remember agreeing to, an interest rate that changed without warning, or a product they want to cancel. The tool queries the underlying dataset — 29 structured product rows extracted across all six modules of the CFPB examination procedures using an Apify Actor and Claude — and returns exactly what applies to that situation: the product definitions, what the issuer was federally required to disclose, the consumer’s cancellation and refund rights, and the exact checkpoint questions federal examiners ask when investigating that issuer.

The architecture is situation-driven — the consumer’s selection determines which dataset rows surface. The interface is built in React and Vite with Bebas Neue and Crimson Pro typography, anime.js animations, and a noir investigative aesthetic designed to feel like opening a case file. It is deployed on a custom subdomain via Vercel. The dataset covers Module 5 Dispute Resolution, Module 6 Add-On Products, advertising and fee disclosure requirements, account origination rules, and account servicing obligations — the full examination procedures, not a subset.

This is not legal advice. This is the knowledge federal examiners have always had, finally made available to the people it was always meant to serve.

Credit Card Rights Navigator →

Was Your Closing Fair? — Mortgage Origination Rights

A mortgage closing is one of the most consequential financial transactions a consumer will ever sign. It is also one of the most deliberately complex — a stack of documents, a table full of fees, and a timeline that moves faster than most borrowers can follow. Federal examiners know exactly what to look for when something goes wrong. Until now, consumers did not.

This is the third tool in the Consumer Financial Rights Catalog. The knowledge foundation is the CFPB Mortgage Origination Examination Procedures — a 49-page federal document covering eight examination modules: Company Business Model, Advertising and Marketing, Loan Originators, Loan Disclosures for Closed-End Loans, Loan Disclosures for Other Residential Mortgages, Appraisals, Underwriting, and Examiner Conclusions. An Apify Actor scrapes and parses the examination procedures PDF alongside the CFPB Supervisory Highlights Issue 33 (Spring 2024), passes each module independently to Claude with a constrained factual extraction prompt, and structures the output into 104 unique dataset rows — each containing a plain language definition, product category, CFR citations, authorization requirements, disclosure requirements, and the exact checkpoint questions federal examiners use in the field. The 19 prohibited misrepresentation categories under the MAP Rule (12 CFR 1014.3) are each represented as individual rows. The dataset passes a full ten-point quality test: zero empty definitions, zero empty examiner checkpoints, 99 of 104 rows with CFR citations, and zero duplicates.

The consumer-facing tool is situation-driven. A borrower selects the problem they encountered — fees they don’t understand at closing, loan terms that changed before closing, a denial without a clear explanation, a rate different from what was quoted, or a right of rescission they want to understand. The tool queries the dataset and surfaces exactly what federal law required the lender to do, what the consumer’s rights are, and what a federal examiner would specifically investigate in that situation. The interface is built in React and Vite with Playfair Display and IBM Plex Mono typography, anime.js v4 animations, and a legal-document aesthetic — dark, authoritative, high contrast — designed to feel like evidence, not a product. It is deployed to a custom subdomain via Vercel.

This is not legal advice. This is what federal examiners know, structured for the people those examinations were always meant to protect.

Was Your Closing Fair? →

Did This Debt Hurt Your Credit Illegally? — Debt Collection Credit Report Rights

The CFPB Debt Collection Examination Procedures have always been a public document. Federal examiners used them to walk into debt collection agencies and determine whether consumers’ rights were being violated. The legal standards were codified. The findings were published. None of it was secret. All of it was inaccessible — written in regulatory language, buried in government archives, and never once delivered to the consumer sitting across the desk from the collector being examined.

This is the fourth tool in the Consumer Financial Rights Catalog — a proprietary series of structured datasets and consumer-facing applications built on federal examination standards. Each dataset in the catalog represents original research and original work: federal examination procedures extracted, structured, and documented to a professional standard, with every consumer right, CFR citation, legal requirement, violation indicator, and examiner checkpoint organized into a queryable, licensable knowledge base. The dataset underlying this tool is a proprietary asset — built from publicly available federal documents, but organized, structured, and maintained by Safe Passage Strategies LLC.

The consumer-facing tool is diagnostic. A person with a collection account on their credit report answers five questions about how that debt was reported — whether the collector contacted them before reporting, whether a dispute was ignored, whether the amount is accurate, whether required notices were sent, and whether the debt resulted from identity theft. The tool surfaces the exact federal laws that apply, the CFR citations, what the collector was legally required to do, and what a federal examiner would specifically investigate in that situation. The interface is built in React and Vite with Bebas Neue and DM Mono typography, anime.js v4 animations, and a clinical diagnostic aesthetic — deep forest green on white — designed to feel like receiving a professional assessment of your legal standing rather than browsing a consumer help center.

The information in this tool was always yours. It was always public. It was never made available to you in a form you could use. That is no longer the case.

Did This Debt Hurt Your Credit Illegally? →

Veterans Rights & Government Accountability

A tool built to correct a documented failure inside a federal system — not as a proposal, not as a concept, but as working software deployed the same day the problem was identified.

Appeal Evidence Bridge

When a veteran’s Board of Veterans’ Appeals case is open for new evidence, VA.gov lists a P.O. box and a fax number. It does not tell the veteran that the VA’s own electronic submission tool — QuickSubmit — already exists and already works. That omission is not a technical limitation. It is a policy failure that has cost veterans time, money, and missed deadlines for years.

I identified this gap from inside my own active appeal. I built the fix the same day. Appeal Evidence Bridge is a browser extension that runs silently on VA.gov and fires automatically when it detects that a veteran’s appeal is open for new evidence. It injects a banner with a one-click button that takes the veteran directly to QuickSubmit — the submission path the VA never surfaces. The entire proof of concept took less than 15 minutes to build and validate on a live VA.gov appeal page.

The extension is published to the Chrome Web Store under Safe Passage Strategies — currently under review by Google, pending public release. The source code and a formal brief documenting the defect — addressed to the VA Office of the Chief Technology Officer and to congressional offices — are published openly on GitHub. The brief makes one request: add the link that should have always been there.

This project did not stop at the prototype. After proving the fix in under 15 minutes on a live VA.gov appeal page, I packaged the extension for the Chrome Web Store, published the complete documentation on GitHub, and submitted the solution through every available channel simultaneously — technical, legislative, and legal. A formal bug report was filed directly in the VA’s own vets-website codebase. A Pull Request containing the eight-line fix was submitted to the VA’s GitHub repository. Cover letters were delivered to Senator Markey, the House Committee on Veterans’ Affairs, and the VA Office of Inspector General. A permanent public record now exists that no one can erase.

What this project demonstrates is not just browser extension development or DOM injection or Chrome Web Store publication. It demonstrates the ability to identify a systemic failure precisely, document it with legal soundness, build the technical proof, and deliver both the solution and the demand through every channel available — simultaneously. The VA appeals backlog is not a mystery. It is the predictable output of systems that were never designed to be efficient, maintained by institutions that have no financial incentive to solve the problems they administer. Solved problems end funding cycles. This fix took 15 minutes. That gap is not accidental.

The repository at github.com/IainAmosMelchizedek/appeal-evidence-bridge contains the complete record — the code, the extension, the formal brief, the congressional letters, the OIG complaint, and the PR submitted to the VA’s own codebase. It is the intersection of legal precision and technical execution. That intersection is where I operate.

The contribution process itself proved the point. The VA’s own contributing guidelines require that bug reports be labeled as such prior to submission. When I attempted to comply, the Labels field in the issue creation interface was visible but non-interactive — externally accessible contributors cannot apply labels. The policy requires compliance with something the system does not make available to the people it governs. This is not an edge case. It is the pattern. Institutions that manufacture problems also manufacture compliance requirements that cannot be met, so that any contribution that threatens the status quo can be dismissed on procedural grounds rather than substantive ones. I documented the omission explicitly in the PR itself — stating that the intent to label the issue as a bug was the functional equivalent of the label itself, and that the failure to apply it was a result of access restrictions imposed by the repository configuration, not a failure to follow the guidelines. You read the policy. You identify what they require. You document why you cannot comply through no fault of your own. Then you state your intent on the public record so the procedural rejection has nowhere to land. That is how you meet a manufactured obstacle — not by fighting it, but by making it visible.

View on Chrome Web Store →    View Repository →

Safe Passage Strategies is Iain Melchizedek — singular, unfiltered, unbound, uncompromised. No committees. No politics. No legacy systems. The mandate is clear: execute the work and ensure it performs within the capitalistic reality of the United States, where private enterprise is the only operating framework.