From Prompt to Proof, Part 1

From Prompt to Proof: How I Use ChatGPT, Codex, and ChatGPT Work Across a Company and a Life

For a long time, most of my work with ChatGPT ended with an answer.

I would bring it a problem, a rough idea, an email, or a decision I was trying to make. It helped me research, organize the facts, challenge an assumption, or turn scattered thinking into something I could use.

That was valuable. It was also incomplete.

Today, the answer is usually where the real work begins.

I now use ChatGPT, ChatGPT Work, and Codex across company operations, property management, software, content, research, and decisions outside the company. Some of that work is tangible. Some exists as plans, drafts, code, tests, or workflows under human review. Other parts are still experiments.

I am not prepared to call the whole system autonomous, reliable, or proven. I do not have an honest system-wide measurement for how much time it saves, how often it fails, or how much business value it has created.

That matters because the gap between an impressive result and a trustworthy result is where most of the risk lives.

This series is about that gap.

Evidence status: M1. My use is real and documented. The broader operating result remains unmeasured.

The products have changed. The accountability question has not.

OpenAI announced ChatGPT Work on July 9, 2026. OpenAI describes it as an agent in ChatGPT that can work across connected applications and files, carry longer projects through multiple steps, create work products, and use scheduled tasks. OpenAI also says users can control access, check-ins, and actions that require approval. Source: https://openai.com/index/chatgpt-for-your-most-ambitious-work/

OpenAI describes Codex as its coding agent for work such as pull requests, refactors, migrations, tests, and code review across ChatGPT, editor, and terminal surfaces. Source: https://openai.com/codex/

Those are OpenAI's descriptions of its products. They are not evidence that my workflows are dependable.

My evidence is narrower: the work I assigned, the artifacts that exist, the decisions I changed, the code and tests I can inspect, and the failures I can verify.

The division of labor I use today

I do not use these products interchangeably.

ChatGPT is where I think with another mind in the room.

I bring it a decision before I have reduced the decision to a tidy brief. I ask it to reconcile competing plans, test an argument, show me where the evidence is thin, and surface a second-order consequence I may be moving past too quickly.

The value is not agreement. Agreement is easy and often useless. I need the system to understand enough context to tell me when the plan is weak, the recommendation is too confident, or the question itself is wrong.

I use ChatGPT Work when an assignment depends on context spread across sources and the deliverable requires more than a response.

I have used it to reconcile execution plans, review open commitments, and shape a CEO closure structure that brings material items into a short decision queue: the issue, owner, deadline, recommended action, and evidence required for closure.

The structure exists. Related implementation work exists. I do not yet have enough daily operating evidence to claim that it catches every material item or has reliably reduced rescue work.

The same distinction applies to revenue. An AI system can surface a possible follow-up, proposal, referral, or neglected opportunity. Finding an opportunity is not closing revenue. Until the opportunity can be traced to action and an attributable result, it remains a lead, not proof.

Codex is where the work becomes technical.

I am not a software engineer. I am a property-management operator with a clear view of the systems, controls, and failure modes our industry needs. Codex helps translate that operating judgment into repository changes I can inspect.

I use it to review pull requests, diagnose failed checks, inspect overlapping changes, strengthen tests, and prepare repairs. A current example is this franchise itself. The first content package was merged, but not into the current main branch. The merge status was real. The intended outcome was not.

The correction required a clean replay onto current main, preservation of intervening work, a new pull request, and a separate repair after two security checks produced false positives. Only after the corrected package merged and both CI workflows passed could I say the repository prerequisite was complete.

That is the distinction this series will keep making.

A merge is not necessarily the desired integration. Integration is not deployment. Deployment is not adoption. Adoption is not proof of a business result.

The questions I ask at each stage

• What changed?
• Which source governs the work?
• What evidence supports the change?
• Which tests passed?
• Which relevant conditions were never tested?
• What happens when the normal path fails?
• Which actions remain human-only?
• Who owns the result after the agent stops?
• What remains unproven?

Those questions matter more to me than whether a demo looks impressive.

The same standard applies beyond software

I use AI to study my own content performance instead of relying on generic best practices. Direct LinkedIn Creator Analytics changed the way I think about my strongest material. The clearest evidence points toward market risk, owner consequences, operating doctrine, and real proof.

That does not mean every AI article will perform. AI is a new editorial lane, and it still has to earn attention from the audience I actually serve.

I use AI to develop ideas for articles, speeches, and Property Management Excellence without giving it final ownership of my voice. A polished draft can still be wrong for me. I have rejected copy that was technically clean but lacked conviction, overexplained the obvious, or sounded like someone performing leadership online.

I use it for research and decisions outside the business, too. That work has reinforced the same lesson: confident synthesis is not the same as a decision that survives real conditions.

I will publish those cases only when the facts are verified and the personal details belong in the public record.

What I mean by prompt to proof

A prompt is an instruction. It does not define the whole assignment.

Before I give an AI system meaningful authority, I want seven things to be clear:

1. The goal. What outcome are we trying to produce?
2. The source context. Which files, systems, people, and facts govern the work?
3. The authority. What may the system read, draft, change, send, approve, or never touch?
4. The human-only boundary. Which judgment or action remains with a person regardless of confidence?
5. The exception path. What causes the system to stop, and who receives the problem?
6. The evidence. What must exist before the work can be accepted as complete?
7. The owner. Which person remains accountable for the result?

The evidence should match the risk.

A draft may need a source check and a final edit. A code change may need an inspected diff, regression tests, security review, and clean checks against the correct branch. A financial workflow may need reconciled totals, source-system confirmation, approval evidence, and proof that every skipped item reached a human review lane.

Property management makes this standard impossible to ignore.

An agent that touches an invoice, work order, owner report, lease record, or tenant communication operates inside financial, legal, ethical, and human consequences. Speed is useful. It does not excuse a weak system of record, unclear approval, or missing exception.

The Owner Mindset still applies. Someone must understand the consequence for the asset, the owner, the tenant, the team, and the trust holding the relationship together.

Where the work stands

I use these systems throughout my work now. I have real drafts, decisions, plans, repository changes, tests, and completed pieces of work to examine.

I also have unresolved questions.

I do not have a complete baseline for time saved. I have not measured error rates across every workflow. Several systems are designed or built but have not earned a claim of reliable production autonomy. Source connections are not equally complete, and output quality still rises or falls with context quality.

That is why this first article remains M1.

Future installments will move one workflow at a time through the evidence: the real problem, division of labor, boundaries, artifact, failure, current status, and result if a result can be proved.

I want AI to carry more of the work. I also want the people affected by that work to know exactly who remains responsible.

The contract is where I start.

Get the Prompt-to-Proof Delegation Contract

Before you give AI authority, define the goal, source context, permitted actions, prohibited actions, escalation conditions, required evidence, and human owner.

The Prompt-to-Proof Delegation Contract puts those decisions on one page.

Primary CTA destination: /from-prompt-to-proof/delegation-contract/

Use the Prompt-to-Proof Delegation Contract

Continue to Part 2: The Work Is Not Done Because AI Says It Is