I am a line cook, a business management graduate, a self-taught builder, and the founder of Top Shelf Service LLC.

My technical education has been project-driven. I try to turn a real operating problem into a working system. When the system fails, I diagnose the boundary I misunderstood, learn the professional concept behind it, rebuild, and verify the result.

This site is the durable record of that process. It separates what I built from what I planned, what failed from what worked, and what I believe from what the evidence can actually prove.

How the lesson happened

01 / BUILD

I kept working in kitchens, graduated in business management, and tried to turn operating problems into systems I could actually use.

02 / FAIL

At first, it was easy to treat either credentials or working code as universal proof. Neither is. A job title does not prove a system works, and a passing build does not prove judgment.

03 / DIAGNOSE

Domain experience, technical implementation, and verified outcomes are different evidence classes. Each answers a different question.

04 / LEARN

My useful advantage is not pretending to know everything. It is combining real operating context with a willingness to build, fail, investigate, and verify.

05 / REBUILD

I now treat each project as a learning laboratory. Claims get labeled as built, failed, planned, or unknown instead of being compressed into a highlight reel.

06 / VERIFY

My work history supports the operating context. My correction that I graduated supersedes older education wording. Project artifacts support active building. Each technical claim still needs its own evidence.

07 / EXPLAIN

The masterclass records what I tried, what broke, what the professional concept is called, what changed afterward, and what remains unproven.

What you can carry forward

The big-picture lesson

Credibility is not a credential contest. It grows when specific claims stay attached to inspectable work, honest limits, and corrections when the evidence changes.

Project-specific lesson

My public identity needs the same version discipline as a technical claim: current roles, completed education, operating experience, and self-description cannot be copied forever from an old résumé.

TOS capture: Public Identity and Claim ContractTurn the lesson into an operating rule so I do not have to learn it twice.
  • Give every biographical claim an owner-approved source and review date.
  • Require separate evidence for titles, credentials, customers, revenue, and outcomes.
  • Never let one project artifact prove an unrelated public claim.
  • Let corrections supersede old wording without hiding the audit trail.
  • Allow unknown to remain unknown.

What I'm trying next

Publish one precise introduction, record the good-faith questions it creates, and use those questions to identify what the audience still does not understand.

Next: Why I started building