# Hum(a)in Kit v0.2

Hum(a)in: the intelligence remains human, the (a)rtificial part is optional and removable.

The toolkit from the article [Hum(a)in Design Principles](https://nicolaspalazzo.com/en/human-first), October 2026.

Free to use and adapt, with credit: Nicolas Palazzo, nicolaspalazzo.com ([CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)).
Using this in your team? [I'd like to hear about it](https://nicolaspalazzo.com/en/contact).

## How to use it

Pick a risk level for your project, then tick the checklist for that level.
Paste the rules block into your AI tool's standing instructions.

## The four principles

1. **Build it, own it.** Humans should be able to understand, fix and use the products with or without AI.
2. **/loop, make me wiser.** The interactions between humans and AI should provide learning opportunities for humans, allowing them to improve their skills while augmenting their agency.
3. **Pack it, carry it.** The products we build should remain "AI agnostic", meaning that they shouldn't rely on a single AI services provider. They should also have a fallback mode for when AI is not available.
4. **Lend it, take it back.** When AI can act on our behalf, we hand over part of our agency. Every permission we give it should have a human owner, an end date and a way to undo it.

## Risk levels

Pick a level at the start of each project, and move it up as soon as other people start relying on it. The conditions for each level add to the level before it.

|Level|What it is|Ask yourself|What it requires|
|---|---|---|---|
|0. Throwaway|Experiments and demos you'll delete|Would I care if it vanished? No|Nothing|
|1. Personal|Things only you use, like your portfolio|Would losing it cost me time or money?|A backup, a short README, accounts in your name|
|2. Shared|Used by a team, clients or the public|Would someone else be stuck if it broke?|The full checklist and the explain-it-back check|
|3. Critical|Handles money, personal data or someone's livelihood|Could a failure hurt someone?|The takeover test and a human on call|

/loop, make me wiser applies at every level: there's always room to learn and regain agency.

## The checklist

The number in brackets is the level from which the item applies.


**Can someone understand it?** (Build it, own it)

- [ ] (1) A README in plain language says what this is, how to open or run it, and where it lives
- [ ] (2) It only uses tools from your approved list (see the AI rules below)
- [ ] (2) A decision log, a few lines per choice, says what was picked and why
- [ ] (2) The README was checked against the project at the last change, not only at launch

**Do you own it?** (Build it, own it)

- [ ] (1) The accounts, domain, hosting and data are in your name
- [ ] (1) A backup exists outside the AI tool you built it with
- [ ] (1) Passwords and keys live in a password manager, never only in a chat
- [ ] (2) Everything is in Git or a similar history, so any change can be undone

**Can it survive without one AI company?** (Pack it, carry it)

- [ ] (2) The project is plain files a different AI tool or a developer could open
- [ ] (2) Every outside service is listed, with what happens if it fails
- [ ] (2) If it uses AI while running, it still does something useful with AI switched off
- [ ] (3) Someone besides you knows how to put it back online from scratch

**What can it do on its own?** (Lend it, take it back)

- [ ] (1) You have a list of the AI tools and agents you gave access to, and what they can reach
- [ ] (2) Each agent has its own account or keys, never yours, with only the access it needs
- [ ] (2) Each agent has a named human owner
- [ ] (2) Access nobody used in the last 30 days is removed
- [ ] (3) Anything that can't be undone (sending, paying, deleting) waits for a human approval
- [ ] (3) You can switch an agent off in one move, and you've tested it

## Two checks and a safeguard

Start with the easiest one that matches your level.

### #01 - Explain it back (level 2)

Take five minutes, on your own. Close the AI. Explain out loud, or in a short note, what the project does, how it's organized, where the data lives, and what each agent can do on its own. Anything you can't explain goes in the README or the decision log before you ship.

### #02 - The takeover test (level 3)

Give someone who didn't build the product only the files and the README, with no AI and no help from you.

The test is successful if they can:

1. Say in their own words what it does
2. Open or run it on their own machine or account
3. Make one small change, like a piece of text or a color
4. Find where the data, accounts and agent access live
5. Undo that change from the saved history

If they get stuck, fix that, then run the test again. A non-technical colleague can do steps 1, 4 and 5. Steps 2 and 3 might need a developer.

### #03 - A human on call (level 3)

Keep an expert (or more) you trust in the domain, someone you can pay for a few hours when something breaks. Have them run the takeover test at least once a year, so they already know the project if you need them in the future.

## Rules to give the AI

Paste these at the start of a project, or into the AI's standing instructions: a `CLAUDE.md` or `AGENTS.md` file, or your Cursor rules. Fill in the approved tools list once with an expert you trust, so you don't have to judge tool choices only by yourself. The skills list belongs to you: feel free to add the topics you want to learn or get better at.

```
Hum(a)in rules for this project (risk level: __)
Approved tools: __________ (anything else, ask me first)
Skills I want to learn: __________

1. Only use tools from the approved list. If you need something else, explain why in plain words and wait for my answer.
2. Keep the code simple and readable, even if a clever version would be shorter.
3. Explain important choices without jargon and tell me what the alternatives were.
4. Keep the README and the decision log up to date with every change.
5. Keep everything in plain, standard files that another AI tool or a developer could open. Nothing that only works inside this tool.
6. If a feature uses AI while running, build a fallback that still works when AI is off.
7. List every outside service, account and key the project needs.
8. At the end of each session, write three lines on what a new person would need to know to take over.
9. If I ask for something that breaks these rules, tell me before you do it.
10. When I start a new task that matches or is tied to a skill on my learning list, ask if I want to learn it or delegate it.
11. Never use my own accounts or keys. Ask me before any action that can't be undone.
```

## Who checks, and when

On a solo project you hold all three roles.
Once a project reaches level 3, bring in a second person as the reviewer: the takeover test only works with someone who didn't build it. If you're working alone, that person can be the expert from your safeguard.

| Role     | What they do                                                                           |
| -------- | -------------------------------------------------------------------------------------- |
| Builder  | Works with the AI, ticks the checklist, keeps the README and decision log current      |
| Reviewer | Runs the takeover test on level 3 projects. <br>Must be someone other than the builder |
| Owner    | Holds the accounts and decides whether a known gap is acceptable                       |

Check before launch, after any big change, and when a project moves up a level.

When a check fails, write the gap down and fix it. If you decide to live with it, the owner writes the reason in the decision log.