Provenance record Authorship, not ownershipTimestamped by commit historyVerifiable on request

Authorship, Provenance, and Verification

What this portfolio claims, what it deliberately does not claim, how each claim can be independently checked, and exactly what is withheld from every page and why.

Authorshipclaimed and evidencedOwnershipexplicitly not claimed4 tiersof independent verification10categories withheld without exception

What this record is

A record of authorship. Not a claim of ownership.

This repository states which systems I personally designed, built, and shipped. It is timestamped by the commit history of the repository itself, which is a public, append-only record under an account in my name.

It is not a claim of ownership, and it should not be read as one. Systems built in the course of an employment or client engagement belong to that employer or client. Intellectual property in every system described in this repository rests with the organization that commissioned it, and nothing here transfers, licenses, or offers any part of it.

What is mine is the architectural judgment, the engineering, the operating discipline, and this account of it. That is the claim, and it is the claim a hiring manager or a client actually needs evaluated.

The distinction that governs this repositoryAuthorship is who built it. Ownership is who holds the rights in it. These pages assert the first and expressly disclaim the second.

The claim, stated precisely

Both halves matter. The second half is the load-bearing one.

What I claim

  • I was the sole architect and builder of each system in the ledger below, working with AI assistance and without a development agency or contracted engineering team.
  • I designed the system, wrote the implementation, deployed it, and operated it in production.
  • These write-ups are my own account of my own work, in my own words.
  • Figures quoted are measured, or rounded down and banded from measured values. None is estimated upward, and none is projected.
  • Where a system is not yet live, the page says so in the first screen, in the status line, and in the ledger.

What I do not claim

  • I do not claim ownership of, or any rights in, any system built under an employment or client engagement.
  • I do not claim these pages are endorsed by, authorized by, or published on behalf of any employer or client. They are published in a personal capacity.
  • I do not claim credit for work done by anyone else. No such work is described here.
  • I do not present scoped, specified, or in-build work as shipped.
  • I do not offer any system described here for license, sale, reuse, or reproduction.

The build ledger

Eight systems and programs, with role and status stated plainly.

SystemWhat it isMy roleStatusDocumented
AI Reply AssistantRetrieval-grounded draftingSole architect and builderLive, in daily production2026-08-16
Reply Training ConsolePer-department voice trainingSole architect and builderLive2026-08-16
Call-Time Dispatch AssistantConstraint-based bookingSole architect and builderLive, in tuning2026-08-16
Dispatch UnderstudyExpertise capture to rulesSole architect and builderLive, capturing2026-08-16
Campaign AutomationGated self-serve campaignsSole architect and builderIn build2026-08-16
Invoice AutomationDeterministic draftingSole architect and builderIn build, in diagnosis2026-08-16
Production Reliability LayerObservability and recoverySole architect and builderLive, under all of the above2026-08-16
Search, Review, LifecycleAEO, reviews, CRMProgram owner and builderLive. Voice agents scoped only2026-08-16
On the Documented column

The documented date is the date the write-up was committed to this public repository. It is not the date the system went live. Where a go-live date matters to you, ask and I will give it to you directly rather than assert it here without evidence you can check.

On status labels

Live means running in production and in daily use. In tuning means live and being scored against real behavior. In build means implemented but not yet in production. Scoped means specified and not built. These labels are used consistently and are the single easiest thing to check in a walkthrough, which is precisely why they are accurate.

How to verify any of this

Four tiers, increasing in strength. The strongest is available on request.

  1. Timestamp: this repository's commit history Every page here was committed to a public repository under an account in my name, on a recorded date. Commit history is append-only and cannot be silently backdated without leaving evidence in the repository. This establishes when each claim was made, which is the foundation everything else rests on.
  2. Corroboration: independent surfaces maintained over time The same claims appear, in the same terms, on surfaces I maintain separately and publicly: my LinkedIn profile, my CV, and my public GitHub account. Consistency held across independent surfaces over months is considerably harder to manufacture than any single document, and inconsistency between them would be trivial to spot.
  3. Demonstration: a live walkthrough I will demonstrate the running systems on a screen share, on request, subject to the confidentiality obligations that govern them. This is the strongest proof available and it is offered to any serious party. Someone who did not build a system cannot narrate its edge cases, its failure modes, or the reason a particular decision was made the way it was.
  4. Reference: people who were there Named references who supervised the engagement or worked alongside it can be provided on request. They can confirm scope, role, and delivery directly, without me in the middle of it.
Why this page exists at all

Anonymized case studies are, by construction, unverifiable on their face. Removing the client name removes the reader's ability to check. The honest response is not to name the client anyway. It is to say clearly what is being claimed, what is not, and exactly how a serious reader can satisfy themselves privately.

What is withheld, and why

Every page in this repository is written to one fixed disclosure standard.

The following are withheld from every page in this repository, without exception, regardless of how much they would strengthen a claim:

  • The name of the employer or client, and any detail sufficient to identify them
  • Source code, in whole or in part
  • Prompts, prompt templates, and system instructions
  • Credentials, keys, tokens, endpoints, hostnames, and internal identifiers
  • Schemas, data models, and internal record structures
  • Customer data of any kind, in any form, including anonymized or composited
  • Named third-party vendors in the client's operational stack
  • Exact commercial figures, contract terms, and pricing
  • Screenshots or recordings of live systems
  • Any material subject to a confidentiality obligation

Figures that do appear are rounded, banded, or expressed as ranges, and are included only where the band itself carries no confidential information. Where an honest description of a result would require a confidential figure, the result is omitted rather than approximated into something that misleads.

Third-party vendors in a client's operational stack are described by category, such as a managed vector database or a field-service platform, rather than by name. A company's tooling choices are its own information to disclose.

Screenshots specifically

Screenshots of live systems are not published in this repository. A screenshot is the single highest-risk artefact in a portfolio: it carries customer names, phone numbers, message contents, internal identifiers, and vendor branding, and blurring is routinely insufficient. Every diagram in this repository is drawn in CSS from public description, so there is nothing in it that could have leaked.

Method statement

One person, AI augmented, no agency, no inherited codebase.

Every system listed was designed and built by one person working with AI assistance. There was no development agency, no contracted engineering team, and no inherited codebase to extend.

I state the AI assistance plainly, here and on my CV, because the claim I am making is about architectural judgment, scoping, delivery, and operations, not about keystrokes. Anyone evaluating me should evaluate the decisions: where the model was allowed and where it was structurally excluded, what fails closed, what degrades, what a person still has to approve, and what happens at three in the morning when a third party goes down.

The thing worth checking

The distinguishing work in this portfolio is not that AI systems were built. It is where the boundaries were drawn: a model that never touches a total, a capture tool that cannot be repurposed into surveillance, a form field that was removed rather than validated, and a watchdog that does not trust a job to report on itself. Those are the decisions to interrogate.

Corrections and takedown

A standing commitment, not a disclaimer.

If anything in this repository is inaccurate, or if a rights holder considers any part of it to exceed the disclosure standard set out above, contact me and it will be corrected or removed promptly. No dispute process is required and none will be raised.

Contact: consultwithpatrick@gmail.com

In summary

Authorship claimed, ownership disclaimed, verification offered.

This repository records what I built, states plainly that I do not own it, withholds everything that belongs to the organizations that commissioned it, and offers a live demonstration to anyone who needs more than my word. That is the strongest honest position available for anonymized work, and it is the one I have taken.