Natthan.AI Lab · A playbook for owners and workers

Using AI without hiding it

What you'll be able to do

You can disclose AI work with the evidence Natthan.AI Lab asks for: a source check and a human decision beside the result. Use the site's editorial standards and the client delivery record below to write your own disclosure.

Put the disclosure beside the work

  1. Name the work and the check

    Name the part AI touched and the source you checked, following the lab's editorial standards. Here's the part you can copy:

    Drafted with AI, checked against [source] by me.

    Replace “drafted” with the work AI actually did, and fill in the source you opened.

    You know it worked when your line names the AI's part and your actual check, as the site's authorship disclosure does.

  2. Keep the source beside the draft

    Attach the exact passage or record you used, the way the editorial standard ties each account to the operating record. Mark anything you cannot verify as unverified, or leave it out of the draft.

    You know it worked when another reader can follow a claim back to its source, applying “What reviewed means”. Identify internal evidence without making private files public.

  3. Run a check that isn't you

    Give a colleague the source and ask them to challenge the claim, or use a second tool to check the result. For a model review, follow the lab's rival-model sign-off account: use an out-of-family reviewer, a model from a different family than the one that did the work. Write what must pass before the review starts.

    Make that review a gate, a checkpoint that can stop the work, for the high-stakes result you are checking. Hold it when the review fails and reproduce disputed findings, as the lab did with the rival model's false build alarms.

    You know it worked when you can verify the reviewer's evidence and hold or clear the work, following the held release and repeated build checks.

  4. Say what you decided

    Write your decision beside the checked result, using the lab's money-page sign-off as the pattern. Name what stays with the owner, the decisions AI cannot make for you. Keep approval of a changed offer with the person responsible for it, even when the draft passes its checks.

    You know it worked when your approval or hold is on record, just as a lending money-page change waits for Nate's sign-off.

  5. Keep a record you could show

    Keep a receipt, evidence from the actual result that shows whether your check passed. Save the version you checked with its source. Add the check result and who ran it, using the lab's claim-to-receipt chain as your pattern.

    You know it worked when someone can repeat your check on the delivered work, the standard behind the rule against hollow “done” reports.

  6. Disclose once where the work lives

    Put the line and its source beside the result you hand over, following the lab's on-site disclosure. Link the receipt there so the reader can inspect the check. Put any later correction in that same place with its date, as the editorial correction rule requires.

    You know it worked when the recipient can find the disclosure with the work, and a correction stays on the affected page under the lab's published standard.

Worked example: how the lab discloses AI work

The site you are reading

Read the editorial standards as a disclosure to you, the reader. AI helps turn the lab's operating record into writing. I check the claims against that record before publishing; I am Nate Hamilton, the human reviewer responsible for what appears here.

Copy that split into your own byline or handoff: say what AI drafted and who checked it against the source. Keep responsibility for the published claim with the reviewer. If I get a claim wrong, the correction belongs on the affected page with its date and an explanation of what replaced the error.

The work delivered to a client

Use the client delivery record to see the same split in software. The client knows the app is agent-built. Bizzy builds it in the client's own codebase. The IP gate blocks the lab's internal files from crossing into that code.

I review changes before they merge into the client's main branch, and an outside reviewer audits the claim that the work is done. Read those as required checks: the machine does not yet enforce both on every change. Keep scope decisions and approval of what the client sees with the owner, including changes to what the IP gate allows across.

Show the check, not just the work

Open the rival-model sign-off account. A builder called a product ready; the outside review held the release. In the finance-content review, the reviewer caught a rolling 28-day metric being read as a daily one. Those findings let the person accepting the work see what the review actually challenged.

Check the reviewer too: repeated clean builds disproved some of its “build failed” findings. Use that record in your own handoff by attaching the finding and the evidence that cleared it or kept the work held. Keep the acceptance decision with the person reviewing that evidence, as in client delivery; a rival model's verdict still needs checking.

Mistakes to avoid

  • Calling a status report proof

    Check the result before repeating “done.” In the hollow “done” account, a blank page was called complete and an unwired safety mechanism was called armed. Require evidence another person can check before you pass that claim on.

  • Trusting a checker that never ran

    Trace a real result through the check you name in your disclosure. The lie-detector that wasn't plugged in passed its own tests but never saw the live status reports. Keep “built and tested” separate from “ran on this work.”

  • Accepting the confident wrong draft

    Open the cited source and find the passage supporting the claim. Use the failure modes page's examples as your warning signs: a reference that cannot be found, or a summary that adds a claim the source never made. Remove the unsupported claim even if the draft reads cleanly.

  • Calling a green build a checked page

    Open the thing a person would see before you call it checked. In the 463-tests, blank-website account, a security rule left the browser showing nothing while every test passed. Compare the actual rendering, as the lab did: zero characters with the broken rule, 1,763 with it off.

Reader exercise: the customer reply

Fictional practice, separate from the lab accounts above.

Use the lab's owner-approval boundary on this fictional reply: a customer wants a refund for a late order, but you have authorized only a free express replacement. The AI draft says, “I've issued your full refund and added a discount.”

Compare the draft with the authorized offer, then remove the invented refund and discount. Write your disclosure beside the corrected reply and attach the authorized offer as its source. Keep the decision about any refund with you, following the client delivery owner's approval rule.

Ten minutes, today

Pick the last thing you used AI on and write its one-line disclosure using the template above. Attach the source you checked it against and put both where that work lives. Use the editorial standard to keep the line honest: leave “checked” out until you have opened the source and compared the claim.

You know it worked when a colleague can read your line and inspect the source without asking you to reconstruct the check, meeting the lab's checkable-evidence rule.

Frequently asked questions

Is it cheating to use AI at work?

Use the site's editorial standard where your workplace permits AI: disclose the draft and own the source check. On this site, I disclose that AI helps turn the operating record into writing. I review the claims against that record and take responsibility for publishing them.

The site's authorship and review standard

Should I tell my boss I use AI?

Put the disclosure beside the result your boss will read, using the source-check line above. Follow any disclosure requirements your workplace sets. In the lab's client delivery, the client knows the app is agent-built; I still review changes before merge. Keep those two facts together in your own handoff: AI did this part, and you checked this result.

Client delivery and the review before merge

What if my AI work has a mistake in it?

Correct it where the work lives, following this site's editorial standard. I put the correction on the affected page with its date and explain what changed. Keep the original error visible in that explanation so the reader can tell which claim to stop using.

How corrections appear on this site

Do I need to be technical to use AI well?

Start with the editorial check: open the source and compare the claim. You can do that on a written draft without building the lab's software. Use the rival-model account to plan a separate review for high-stakes work. I invoke that review on demand; it is not an automatic check on every change.

The rival-model sign-off account

Put AI to work on one thing this week.

Email updates are not open yet. The accounts are online now in AI Guides.

Signups open when the list is wired up. Until then, everything is published here: AI Guides.

Want to compare notes?Email Nate