S6: Manage your team with AI

English edition. S1–S6 are available in English; S7–S9 are published in Japanese.

Handing someone work means handing them information.

On this page

• What you get from this skill
• Why now: work is becoming project-based
• Copy-paste path
• Part 1: design the database
• Part 2: put the team structure in the Ontology
• The dashboard: your company at a glance
• Part 3: give instructions
• Part 4: track progress without micromanaging
• Part 5: accept or reject the work
• Part 6: decide who to work with again
• Part 7: the legal lines
• Part 8: when to hire
• Part 9: contracts and payments as files
• Part 10: grow your relationship capital
• Are you done?
• Teaching S6

What you get from this skill

A small project team — you, AI, and freelance partners — run on your Ontology. At its center is your own dashboard: see the state of the company at a glance, and act on it immediately. Along the way you learn how to design a database on top of AI, using information about people as the example.

1. A dashboard that works as your cockpit — private to you, readable on your phone. It’s the backbone of S6; items 2–6 are all grown as fields on this screen
2. Where data lives and how it’s protected — information about people kept separate, with clear access limits
3. Team structure — who’s responsible for what, and who decides what
4. Instructions — a format that lets AI and people act without guessing
5. Acceptance — checking delivered work against pre-agreed criteria
6. Evaluation — deciding with evidence whether to work with someone again, and how to improve

What S6 doesn’t cover: company-wide HR (handbooks, time-tracking systems, payroll and benefits administration), HR-department-scale databases and security, and large-organization appraisal systems. Start on those and you drift into becoming a systems integrator. S6 sharpens a pattern for running small projects with little management overhead. Combine several and you can build a large organization (S7, Japanese).

---

Why now: work is becoming project-based

Across every kind of work, the skill of working with others is becoming essential.

AI is making work individual. One person can now hold research, analysis, and documents that used to be split across roles. Organizations are shifting toward a partnership model: each person owns specific projects, specialists gather for a goal and disband when it’s done. When everyone owns their piece, choosing whom to work with — and what to hand them — decides the outcome.

Hiring has become much heavier. Every employee adds management: hours, reviews, compliance. Each hire pulls you away from decisions and into administration. A rule of thumb we use: each employee should generate at least about twice their fully loaded annual cost in gross profit. Below that, adding people means payroll and management outweigh what they bring in.

So S6 teaches you to design projects around your expertise and run them with the fewest people — AI and freelance partners. Project work means people come and go often, so you need a design where information doesn’t leak at every handover and a clear line for what goes to whom. That’s S6’s order: data first, then structure, instructions, acceptance, evaluation — all visible on one screen.

---

Copy-paste path: the shortest route through S6

Paste these into your AI agent one at a time, in order. Replace everything in 【brackets】 first. Because this involves information about other people, set the sensitivity level (public / internal / restricted / never stored) before putting any data in. Reasons are in Parts 1–10.

① Create separate places for different data (Part 1)

In myproject, create customers/, projects/, and outsource/ (and staff/ if I employ people).
Customer and employee information lives outside ontology/.
Put a README.md in each folder saying what goes there, the default sensitivity (customers and staff: restricted), and who may see it.
Also write the rule that government ID numbers, bank details, health information, and passwords are never stored anywhere here.

② Write the customer data design sheet (Part 1 · if you hold customer data)

Before collecting customer data in customers/, create customers/design-sheet.md.
Ask me one question at a time to fill in these eight items:
purpose / minimum fields / consent (parents' consent for minors) / ownership / who can see it (including contractors and AI tools) / retention period / deletion and export on request / which AI inferences a human must check before they reach the customer

③ Write the project and decision rights (Part 2)

Create projects/【project】/project.md:
goal (with a number and a deadline), period, budget, owner (a person), and a roles table (who / role / contract type / responsible for).
Split AI into an "executor" and a "reviewer."

Then create decision_rights.md in myproject and propose how to sort my work into
Always (no approval needed) / Ask first / Never (humans only).
Contracts, pay, hiring, and ending relationships go under Never.

④ Build the first dashboard (The dashboard)

Read projects/ and build a one-page dashboard showing active projects and their roles at a glance.
- Read-only: the screen never edits data
- What needs action (overdue, awaiting acceptance, awaiting a decision) goes at the top
- No money or pay figures on the screen
- Works at phone width
Build it first in a form I can view right here in this conversation.

After using and adjusting it a few times, decide who may see it (three levels, below). If it goes on the web, put login protection in place before publishing.

⑤ Write one task brief for an AI (Part 3)

Create projects/【project】/tasks/【task-001】.md with these fields:
Goal / Context (what to read) / Constraints / Non-goals / Always · Ask first · Never / Done when (criteria a third party could check) / Evidence (how to report) / Handoff (what's left for the next person)
The task: 【e.g. draft three options for the landing page's first screen】

⑥ Make the freelancer request and the acceptance record one file (Parts 5, 7, 9)

For the request to 【name】, create projects/【project】/acceptance/【acceptance-001】.md:
deliverable / format / deadline / acceptance criteria (3–5, checkable by a third party) / number of revision rounds / review period and reviewer / fee and payment date
Also check that the written terms are complete: both parties' names, date of engagement, scope, delivery date and method, review deadline, fee, payment date and method.
Do not specify how, when, or where they work.

Finally, draft the request email to send them. I'll send it myself.

⑦ Weekly review (Part 4 · every week)

Read projects/【project】/ and reports/ and list:
1. Tasks completed this week (with evidence)
2. Overdue tasks and the likely cause
3. Tasks with no movement for 3+ days
4. People we haven't heard from in 7+ days
5. Rules decided this week that should go into decision_rights.md
Don't write anything. Just list.

⑧ Gather the evidence for “work with them again?” (Part 6)

Read everything in projects/【project】/acceptance/ and draft, for 【name】's work:
1. For each deliverable, which acceptance criteria were met
2. Deadlines and number of revision rounds
3. The points to consider when deciding whether to hire them again (facts only, no speculation)
No scores and no fee recommendations. Save to projects/【project】/review.md. I make the decision.

---

Part 1: design the database

What a database is

A database is where the information you base decisions on is kept searchable, updatable, and with clear rules for who can see it. You don’t need an expensive system. In this framework, the Markdown files in myproject are the database.

A typical database	In myproject
a record	one Markdown file (one person, one project)
fields (columns)	the header block and headings
a table	a folder (people/, customers/, …)
a link to another table	an id or path written in the file
access control	sharing settings per folder
change history	cloud version history or Git

Markdown’s advantage is that AI reads it directly. The same property means anything AI can read also reaches the AI tool and anyone the folder is shared with. The more convenient it gets, the more you must decide where things go and how they’re protected — first.

Scattered data vs. organized data

“Isn’t the Ontology I’ve been building already a database?” — this question always comes up. The answer: half yes.

	Scattered data	Organized data
What it looks like	notes, minutes, email, and reports spread across folders	one record per file, the same header fields, linked by id
Good at	volume; AI can search it to answer unexpected questions	lists, totals, comparisons; can be laid out on a screen
Way out	asking the AI	the dashboard

Scattered data isn’t inferior. Organized data is one way out of it. A large amount of company information in your Ontology is the asset. Conversely, if you force every report to fit the dashboard’s fields, whatever doesn’t fit disappears and the data gets weaker (Part 4).

Security: five layers, as house rules

Before technology, one principle: you’re protecting the people behind the data, not the data. Customers and partners know their information is with you. Trust breaks not only with a leak but with a use they never agreed to. Small projects don’t build a security platform; they set five layers as rules on paper.

① Decide what never goes in. The safest data is data you don’t hold: passwords, API keys, tokens, private keys; government ID numbers, bank details, health information. Keep those in dedicated payroll or HR services, and write in the Markdown only “it’s in the dedicated service.”

② Four sensitivity levels.

Level	Examples	Where / who
Public	published articles, price lists	anyone
Internal	procedures, meeting notes, list of contractors	you and AI; partners as needed
Restricted	customer consultations, contract terms, evaluations	you and AI only; consider anonymizing before AI sees it
Never stored	ID numbers, bank details, health info, credentials	not in Markdown — dedicated services only

③ Minimum access. Separate “can read” and “can write” per folder. Start from “nobody but me” and open only what the work needs; restrict writing most of all — a wrong edit means the AI keeps reasoning from bad information. Never give customers, other companies, or contractors direct access to your Ontology. It’s the whole company’s information; direct access lets them see — and take — far more than they need. Give them a screen built for them (the dashboard, or the customer screen in Part 10) or a document.

④ Decide what the AI may see. How AI tools handle input depends on the contract. Check which tools may receive “restricted” information, and under what terms; until you’ve checked, don’t send it.

⑤ Decide how it ends. When a contractor finishes, a customer leaves, or a partner departs: cut access, and delete what’s past its retention period. Data with no end date is a liability just by being kept.

Keep jokes, fake names, and test data out of the real folders — the S1 principle still holds.

File rules

As files multiply: you can’t find things, can’t tell which is current, can’t tell who changed what. Six rules prevent that.

1. One file = one thing. One person, customer, project, or task per file. Several in one file can’t be permissioned or deleted separately.

2. Always a header block. Add review (when to revisit) to the header you started in S1:

---
id: person-jane-doe
type: person
sensitivity: restricted
owner: me
updated: 2026-10-12
review: 2027-04
---

Now you can ask the AI: “list restricted files not updated in six months.”

3. One source of truth. Never write the same information in two places; one copy gets updated and the other doesn’t. Refer by path instead.

4. Don’t embed attachments. Keep contract PDFs and invoices elsewhere; in Markdown, write the path and the key points.

5. Keep history and backups — version history or Git, with backups stored somewhere other than the original.

6. Give everything you manage an id. Not only customers, members, and projects — products too (a production batch, each item shipped). Searching by name mixes up people with the same name and inconsistent spellings.

• Customer ids don’t require accounts: issue a new id automatically from the email address entered at order or sign-up, and merge later when you learn two are the same person. Repeat-customer analysis and segmentation depend on it.
• Product ids: link a production number to a photo taken before shipping, and keep them for the warranty period (for food, until the best-before date). Answer complaints from records, not memory. Make registration one button just before packing, or it won’t happen.

Scale changes the storage. Up to a few thousand records, Markdown and folders are enough. Tens of thousands of customers, or many outside people writing at once, is when to consider a dedicated database service. The header, id, sensitivity, and single-source rules carry over unchanged. Don’t buy a big system on day one.

Three kinds of people data, kept apart

myproject/
  ├── ontology/
  │     └── people/          contacts and team members  ← from S1
  ├── customers/             customers (new in S6)
  ├── staff/                 employees (only if you employ people)
  ├── projects/              project operations
  └── outsource/             contracts and payments

ontology/ is what the AI reads widely as its basis for judgment. Put customer personal data or employee evaluations there and too much reaches contractors and AI tools. So customers and employees live outside ontology/.

	Employees	Customers	Contacts and members
Where	staff/	customers/	ontology/people/
Holds	role, workload, terms, key evaluation points	only the fields the purpose requires	expertise, what you can ask them, last contact, work done together
Never holds	ID numbers, bank, health (use dedicated services)	“might be useful someday” fields	judgments they couldn’t read and accept
Default sensitivity	restricted	restricted	internal
When it ends	access cut on leaving; deleted after retention	deleted after retention once the relationship ends	tidied up together with the person

Customer data: write the design sheet before collecting (prompt ②). Collect without design, and the more convenient it gets, the more dangerous.

Item	Decide
Purpose	why you collect it; no use beyond that
Minimum fields	only what the purpose needs
Consent	from whom, how; parental consent for minors
Ownership	don’t mix company data and personal data
Access	who sees it, including contractors and AI tools
Retention	no data without an end date
Deletion and export	can you delete or hand it over on request?
Human check on AI inference	how far AI guesses may be shown to the customer

AI inferences aren’t facts. A proposal that presumes someone’s situation loses trust the first time it’s wrong. Decide where a person checks before any personalized proposal goes out.

Contacts and members: grow the S1 ontology/people/ files into a register of people you work with:

## Jane Doe (designer)

- Specialty: landing pages and banners
- Good to ask for: first drafts from a structure, revisions
- Not for: video editing
- Last contact: 2026-10
- Contract: freelance (ongoing)

### Work together
- 2026-06: landing page, $3,000 → inquiries rose after launch
- Related: projects/lp-renewal/, outsource/jane-doe_landing-page.md

Three rules: write only what you could show them — facts about what you asked and what came back, not scores like “reliability: high”; research only public information — an agent can research their company site and talks, never their private life; link investments to S5’s finance/investment/, so the AI can propose who to bring onto a project with evidence.

This data design isn’t legal advice. Data-protection laws (such as the GDPR and UK GDPR in Europe, and state privacy laws such as California’s in the US) set rules on purpose, security, processors, and individuals’ requests. Check with a qualified professional before handling the data.

---

Part 2: put the team structure in the Ontology

The contract type changes how you manage

AI agents, freelancers, and employees are all “members,” but instructions, workload tracking, and evaluation differ. Instructing or managing a freelancer like an employee in particular puts the contract and the reality out of step (Part 7).

	AI agent	Freelancer / partner	Employee
Instructions	detailed (goal, constraints, done-when)	the deliverable and conditions; method is theirs	you can direct the work
Workload	run logs and usage (as cost control)	deadlines and milestones; not hours or location	working hours must be managed
Checking results	evidence-based report, checked by a person	acceptance against criteria	performance review
Evaluation	none (improvements go into rules)	“work together again?” with evidence	HR evaluation

Small projects center on the first two columns. Consider the third only after meeting the criteria in Part 8.

One folder per project

projects/
  └── lp-renewal/
        ├── project.md           goal, period, owner, roles, budget
        ├── tasks/               briefs (one task per file)
        ├── acceptance/          acceptance records (one delivery per file)
        └── review.md            retrospective and "work together again?"

---
id: project-lp-renewal
type: project
sensitivity: internal
owner: me
updated: 2026-10-12
---

## Landing page renewal

- Goal: 1.5× inquiries vs. the same month last year, by December 2026
- Period: 2026-10-01 to 2026-12-15
- Budget: $6,000 (contractors)
- Owner: me

### Roles
| Who | Role | Contract | Responsible for |
|---|---|---|---|
| me | project owner | — | goal, priorities, final calls |
| AI (executor) | structure and copy drafts | — | work within the brief, with evidence |
| AI (reviewer) | checks the executor's work | — | comparing to criteria, list of gaps |
| Jane Doe | design | freelance | agreed deliverables |
| Sam Lee | front-end build | freelance | agreed deliverables |

The owner is always a person — AI can execute and review, but people are accountable. Separate executor and reviewer — self-grading misses things. The roles table becomes the AI’s context — “read project.md and tell me who to ask for what next.”

Decision rights

In small teams “who decides this?” gets fuzzy: the AI runs ahead, or everything comes back for approval. Put one decision_rights.md in place:

Category	Meaning	Examples
Always	reversible work	drafts, organizing notes, research, running tests
Ask first	hard to undo, or visible outside	sending requests, publishing, spending money, major spec changes
Never	humans only	signing or ending contracts, setting pay, hiring or ending relationships, handling credentials

Never let AI decide hiring, pay, or contract renewals and terminations. It assembles the material — evidence, gaps, draft wording. You decide.

---

The dashboard: your company at a glance

The dashboard is the backbone of S6. Data placed in Part 1 and structure set in Part 2 only become usable when they’re laid out on a screen. And everything from Part 3 to Part 9 grows as “one more field on the dashboard.”

With project.md and decision_rights.md in place, you can build the base of a private dashboard you can check from your phone anywhere. No expensive BI tool needed. “Read projects/ and build a one-page dashboard showing active projects and roles at a glance” produces a static page. Much of what paid business apps used to do, you can build from your own Ontology.

Build order: prototype → refine → web

1. Build it inside the AI agent. Agents can render a screen on the spot. But it runs on a temporary server on your computer: close the laptop and it’s gone, and “where was that screen I made?” happens. This is the prototype.
2. Refine until it’s genuinely useful. Use it a few times; fix it until “what should the first screen tell me?” is settled. Somewhere easy to edit — such as an artifact in Claude, a page made inside the conversation — is the fastest place to settle the shape.
3. Put it on the web so your phone can reach it 24/7 — on Cloudflare Pages or similar, with login protection in place first.

Decide who can see it by what’s on it

Who can see it	Good for	Caution
only your computer (localhost)	prototypes; private screens with restricted data	gone when the laptop closes
devices on the same Wi-Fi	screens for a shop or office (e.g. today’s remaining stock and wait time, visible in-store)	invisible outside, but weaker than a login
the web	screens you check on the go; screens shared with customers	login protection is mandatory; don’t overload it with restricted data even then

The basic idea: rather than building a wall nobody can breach, control what you put where. Public screens hold only what wouldn’t hurt if leaked (today’s stock, booking status); important information stays on screens only you can open, or on your machine. Cloudflare Access (Zero Trust) can allow only approved Google accounts; a company Google Workspace account is stronger still.

Money and businesses

Don’t copy money or pay figures onto the dashboard. Revenue, salaries, and fees stay in S5’s finance/; the dashboard reads from there and shows only the essentials — a front window. Copy the numbers and there are two sources of truth that will disagree.

If you run several businesses, give each its own screen, side by side. One screen mixing everything leaves you unsure which number belongs to which. The company (or you) on top, then a tab or card per business.

Add one field each Part

After	Add to the dashboard	From
Part 2	active projects and roles	projects/*/project.md
Parts 3–4	today’s open tasks; overdue and stalled tasks	projects/*/tasks/
Part 5	deliveries awaiting acceptance or rejected	projects/*/acceptance/
Part 6	projects needing a “work together again?” call	projects/*/review.md
Parts 7, 9	missing written terms; this month’s contractor spend and due payments	outsource/

Two basics: the dashboard is read-only — writing happens through each Part’s own steps, never from the screen; and show only what needs looking at now — overdue, awaiting acceptance, awaiting decisions — or you’ll stop looking.

Working on the screen

A dashboard isn’t for staring at. Its value is that the moment you see “bookings are about to exceed what the staff can handle,” you can talk it through with AI right there and act. As it matures, more of your day starts from this screen instead of a dozen browser tabs.

On the screen	What it does	Rule
AI instruction buttons	store common requests (weekly review, importing reports) as task briefs (Part 3) and hand them over with a click	the button produces the instruction only; Always / Ask first / Never live inside the brief
Draft-a-message buttons	from the situation (overdue, awaiting acceptance), suggest a message and draft the email	you read it and send it yourself
Morning brief	the key points from inbox, chat, calendar, and handovers, in fixed slots every morning	keep the slots fixed — if they change daily, you can’t tell what’s missing

Read-only and button-started work fit together: buttons create instructions and drafts — nothing more. Data changes happen through each Part’s steps.

An AI that lives on the screen needs an API. The chat apps and agents you use daily are subscriptions running on your computer. For AI that answers on the screen 24/7 with your laptop closed, you need API access, billed by usage — set a monthly spending cap first. Answering customers with general guidance is well within reach. API keys are “never stored” data: keep them out of Markdown and out of any folder the AI reads; use the hosting service’s secret settings.

Make it something you want to open. You’ll open it many times a day; a look you like helps you keep using it. Just never change what the status colors mean (red = needs action).

The full template and a sample are in the business dashboard template (Japanese; the sample screen is visual and easy to follow). You build your own in mini-works 2 and 3.

---

Part 3: give instructions

Instructions depend on who receives them.

To an AI agent

Vague instructions produce something plausible and wrong. One task per file in projects/{project}/tasks/ (prompt ⑤):

---
id: task-lp-001
type: task
project: lp-renewal
assignee: AI (executor)
sensitivity: internal
updated: 2026-10-12
---

## Goal
Three options for the landing page's first screen.

## Context (read)
- projects/lp-renewal/project.md
- ontology/concepts/target-customer.md

## Constraints
- Touch only projects/lp-renewal/
- No numbers without a source

## Non-goals
- Choosing the design, implementation

## Always / Ask first / Never
- Always: drafting options
- Ask first: sharing outside, research that costs money
- Never: publishing, reading customer data

## Done when
- [ ] Three options, each with a one-line rationale
- [ ] The files each option is based on are listed

## Evidence
List the files created and which criteria each meets. Write "unverified" for anything not checked.

## Handoff
What's left, so the next person can start without reading this conversation.

Nine tips: write the result, not the steps · make “done” checkable by anyone (“three options exist,” not “check carefully”) · always include Always / Ask first / Never · keep it short · one instruction, one outcome · for multi-file work, get a plan first and approve it · when the same mistake happens twice, fix the rules file, not just the output · ask for evidence, not “done” · separate executor and reviewer.

“Let AI do everything and never look” doesn’t work. People own goals, priorities, final calls, and the outside relationships. AI does the preparation and the checking.

To a freelancer or partner

What you give a freelancer is a request for a deliverable, not instructions.

• Give: what’s to be delivered, acceptance criteria, deadline, fee, revision rounds, how it will be accepted
• Don’t give: how to do it, when or where to work, anything like timesheets

Leave the “how” to their expertise — this line also protects the nature of the contract (Part 7). AI drafts the request; a person sends it, including the written terms in Part 7.

---

Part 4: track progress without micromanaging

A team of four or five needs no project-management system — just three habits.

1. One original. Task originals live in projects/{project}/tasks/; lists by deadline and weekly reports are regenerated from them every time.

2. In the morning, look only at what’s open. “List today’s open tasks by deadline.” Mark done by file id (“task-lp-001 done”) — list numbers change daily.

3. Weekly review (prompt ⑦): completed with evidence, overdue with causes, stalled, and new rules for decision_rights.md.

Never let AI write automatically. Scheduled runs only read and list; a person reviews before anything is written. Regenerating the dashboard on a schedule (say 10 a.m. and 6 p.m.) is fine — it only reads and renders.

Take reports in free form

It’s tempting to make an input form matching the dashboard fields. But once only what’s on the screen gets reported, the insights and doubts that don’t fit disappear.

• Take reports as free-form email or chat, or as notes from a conversation (an audio transcript)
• Save each to reports/, one per file, and let the AI sort them into fields
• Tell contractors “just email me — I organize it with AI”; reports keep coming that way

Only problems should come up

Watching everyone constantly wears out both sides. Set conditions for when you get notified — no report for 7 days, a missed deadline, an acceptance deadline approaching — and only those rise to the top of the dashboard. Everything else needs no attention. Less to look at means less gets missed.

When a handover breaks, rebuild it from the record

Someone leaves suddenly, or nothing was written down. Have AI read the past emails and chats in bulk and you can recover most of it:

Read every email with 【customer】 from the last two months and list:
1. Decided policies, with the email (and date) behind each
2. Things we promised but haven't done (make-up sessions, resends, pending replies)
3. Things waiting on their side
Write "unverified" for anything you can't confirm. Don't fill gaps with guesses.

Write what you recover straight back into projects/ or customers/. When there’s nobody to turn to, AI matters most — and once recovered, set up the report folder so you never need to do it again.

Customer and parent emails are mostly “restricted.” Only use AI tools you’ve cleared under Part 1’s layer ④.

Workload by contract type

• AI agents: watch run logs and usage as cost control — never as a measure of results
• Freelancers: watch deadlines and milestones. Don’t track their hours; check progress by how complete the deliverable is
• Employees: working time must be managed by law — outside S6’s scope; use professionals (Part 8)

---

Part 5: accept or reject the work

Decide whether work is done by criteria agreed in advance, not by taste or mood. Write the acceptance record when you place the order, in projects/{project}/acceptance/ (prompt ⑥):

---
id: acceptance-lp-001
type: acceptance
project: lp-renewal
deliverable: first-screen design, first draft
sensitivity: restricted
updated: 2026-10-12
---

## Deliverable
- What: first-screen design (desktop and mobile)
- Format: Figma link
- Due: 2026-10-26

## Acceptance criteria (3–5, checkable by a third party)
- [ ] Desktop and mobile versions exist
- [ ] Headline, image, and sign-up button all appear on the first screen
- [ ] Uses the specified brand colors and fonts

## Terms
- Revision rounds: 2
- Review period: 5 business days after receipt
- Reviewer: me
- If no response within the review period: (decide and write down in advance)

## Result
- Accepted / partly rejected / rejected
- Criteria not met: (which, and how)
- New requests: (anything not in the criteria is a change request, handled separately)

Reject only against the criteria. Requests that aren’t in the criteria are change requests — mix them in and revisions never end. Split big work into phases, each with its own criteria and payment. Acceptance is a quality gate; payment is a legal and contractual gate — a slow review doesn’t move the payment date (Part 7). AI compares against the criteria and lists the gaps; the reviewer — a person — decides. Don’t relax your checks just because AI made or checked the work.

---

Part 6: decide who to work with again

Small-project evaluation is not corporate performance review. Choose one of three patterns:

Pattern	When	What
A: milestone acceptance	freelancers and partners	the accumulated acceptance records are the evaluation
B: light OKRs + weekly check-in	aligning the whole team	1–3 objectives, 2–3 measurable key results each; once a week update only plans, progress, blockers. Kept separate from pay
C: evidence pack + AI draft	renewals with ongoing partners; your own quarterly review	gather evidence, AI drafts, a person checks and decides (prompt ⑧)

Rules: AI is never the evaluator — it checks for missing evidence, orders the timeline, drafts wording; renewals, fees, and endings are human calls · don’t mistake activity for results — hours, message volume, AI usage, and input volume aren’t outcomes · never make OKRs an automatic trigger for pay or renewal · show the other person the evidence · never run freelancers through HR-style performance reviews — look at accepted deliverables and renewal decisions, not attitude or how they spend their time · send improvements to the rules: “it always goes like this” is a template or criteria problem, not a person problem.

---

Part 7: the legal lines

This is a map of the issues from publicly available sources, not legal advice. Rules differ by country, state, and province and change over time. Check your contracts and specific situations with an employment lawyer or other qualified professional where you operate.

Keeping freelance work from being treated as employment

A “contractor agreement” doesn’t settle it — the reality of the relationship does. The tests vary by jurisdiction, but they look at similar things:

Factor	What’s examined
Control	do you direct how, when, and where the work is done, or only the result? Instructions at the level any normal client gives are generally fine
Freedom to decline	can they turn down individual jobs?
Substitution	can they send someone else or use helpers?
Pay	per deliverable, or by the hour for time worked?
Independence	their own tools, multiple clients, a business of their own — or embedded like staff?

For example, the US IRS looks at behavioral control, financial control, and the relationship of the parties, and some states (such as California) apply a stricter “ABC” test; in the UK, employment status and the IR35 rules address the same question. In practice:

• Request deliverables and conditions; leave the method to them
• Don’t set or manage their hours or location
• Judge by how complete the deliverable is. If you want to pay by the hour, check with a professional first

Classification is a whole-picture judgment. Meeting every point above doesn’t guarantee a relationship won’t be treated as employment.

Put the terms in writing — every time

Whatever the jurisdiction, put the terms in writing (email is fine) as soon as you engage someone. Some places require it: for example, New York’s “Freelance Isn’t Free” laws require written contracts for many freelance engagements and timely payment; in the UK, late commercial payments can carry statutory interest. Even where it isn’t required, it prevents most disputes. Include:

• both parties’ names
• the date of engagement
• scope (deliverables or services)
• delivery date and method
• the review/acceptance deadline, if any
• the fee and payment date (or how the fee is calculated)
• payment method
• anything not yet decided, why, and when it will be

These overlap almost exactly with the Part 5 acceptance record. Make your acceptance template double as the written request, and nothing gets left out.

Minimum contract checklist for small projects

• deliverables and acceptance criteria
• deadline, review period, revision rounds
• fee, payment date, payment method
• who owns the work (IP; in many places freelancers own their work unless rights are assigned in writing)
• confidentiality and what information is shared (Part 1 sensitivity)
• how the engagement ends, and what happens then (access cut, information returned or deleted)
• if you also run what you built (a website, a system) for a fee: the scope of operation and maintenance, and who is responsible if a security incident happens. If you only build and hand over, end with the handover of the files

Hours, handbooks, payroll and benefits, and employment contracts are outside S6. If employment begins, use professionals.

---

Part 8: when to hire

Be careful about moving from contractors to employees. Hire someone to manage, not to do the work. AI and contractors do the work; consider employment only when you need someone who can oversee contractors and operations.

The economics, from the rule of thumb above: gross profit of at least about twice the person’s fully loaded annual cost, for every person you’d hire. This is our working guide, not a statistical or legal standard — recheck it against your own numbers. And don’t add fixed payroll before S5’s first two wealth-ladder steps (an emergency fund, no high-interest debt). When employment starts, create staff/ (Part 1): hours, benefits, and payroll go to dedicated services and professionals; the Ontology holds only role, responsibilities, terms, and the points you decide from.

You can start S6 with zero contractors

No budget is needed. First, sort your current work on paper:

Category	Who	Rule
decisions and strategy	you	never hand out
repetitive, routine work	AI	try AI first
one-off specialist work	a contractor	don’t try to do it yourself

Your first contractor can be a tiny one-off job — one banner, transcribing a recording, data entry — through a freelance marketplace. “Design the request, track it, accept the work” is complete in that single job.

---

Part 9: contracts and payments as files

Keep each contractor engagement as one file in outsource/. The workflow (instructions, acceptance, retrospective) lives in projects/; what was promised (terms, fees, payment, ending) lives in outsource/.

---
id: outsource-jane-doe-lp
type: outsource
sensitivity: internal
owner: me
updated: 2026-10-12
---

## Jane Doe — landing page design

### Basics
- Who: Jane Doe (designer)
- Purpose: landing page design
- Contract: freelance (one-off)
- Related: projects/lp-renewal/

### Written terms (Part 7)
- Engaged: 2026-10-12
- Deliverable: landing page design (desktop and mobile)
- Due / method: 2026-10-26, delivered in Figma
- Review deadline: 5 business days after receipt
- Fee: $3,000 (fixed); payment date: a specific date soon after acceptance
- Terms sent by: email (2026-10-12)

### Information shared
- Page structure (sensitivity: public)

### Progress
- [x] Request sent (2026-10-12)
- [ ] First draft delivered and accepted
- [ ] Final delivered and accepted
- [ ] Paid

### At the end
- [ ] Access to shared folders and accounts removed
- [ ] Shared information returned or deleted

Read outsource/ and tell me: this month's total contractor spend, the payments due soon, any finished engagements where access hasn't been removed, and any engagement whose written terms are missing an item.

Feed contractor costs into finance/ monthly, so S5’s analysis can show which contractors drive costs up:

Read every engagement in outsource/ for this month and total the contractor spend.
Add it to the contractor line of this month's close in finance/monthly/.
Tell me which contractors cost more than last month.

---

Part 10: grow your relationship capital

The cycle

add the work you did together to each person file
     ↓
an AI agent adds background from public research
     ↓
AI proposes the best combination for the next project
     ↓
the project's success creates new connections
     ↓
add new person files (loop)

[No background]
"How about asking Jane for the design?"

[With background]
"Jane's landing page lifted inquiries last time. Paired with Sam's front-end work,
 you could shorten the time from first draft to launch."

Turning the same system toward customers

Once you’ve designed customer data (Part 1), you can tailor offers per customer. If S4’s B2C/B2B/B2M is about whom you serve, this is about how: designing for each customer from their data. One condition: write the eight-item design sheet before you start collecting.

A dashboard you share with each customer

The first form of this is a screen per customer, shared with that customer. If you’re selling a property on someone’s behalf, for example, build one screen per property, viewable only by that client:

• days on the market, and inquiries and viewings so far
• the next scheduled report date
• what we’ll do, and what we need from you
• supporting numbers from listing sites, with sources and dates

“How’s it going?” calls drop, and both sides can see on the same screen whether reports arrive as promised.

• One customer, one screen, visible only to them. One line of another customer’s data is a leak
• No internal reasoning. Negotiation strategy, comparisons with other customers, and AI inferences never appear on a customer’s screen
• Common template, custom contents. Start from one template and swap in what matters for each case — nearby sales for land, vacancy time for a rental

---

Are you done?

S6 completes in four stages. Stages 1–3 need no contractors at all.

Stage 1: data design

• No “never stored” information (credentials, ID numbers, bank, health) in Markdown
• Four sensitivity levels decided and in file headers (sensitivity, owner, updated, review)
• Employee, customer, and contact data in separate folders
• (If you hold customer data) the eight-item design sheet written before collecting
• Customers, members, and projects (and products, if any) have ids

Stage 2: team structure

• A project folder with project.md and a roles table (a person as owner)
• decision_rights.md with Always / Ask first / Never
• Your work sorted into you / AI / contractors
• A private, phone-friendly dashboard showing projects and roles
• Who can see it is decided; if on the web, login protection was added before publishing (mini-work 2)
• It shows each member’s last report and days since, plus moving numbers (traffic, sign-ups, clicks) (mini-work 3)
• Money and pay figures are read from finance/, not copied

Stage 3: instructions, acceptance, evaluation

• One AI brief with Goal, Context, Constraints, Done when, Evidence
• A freelancer request by deliverable and criteria, with no method or hours specified
• One acceptance record with criteria
• A review.md where AI gathered evidence and a person decided “work together again?”
• Reports arrive in free form and are saved in reports/; AI sorts them
• Notification conditions are set; only matches rise to the top of the dashboard

Stage 4: running contractors (from the first job)

• Written terms sent to the contractor
• The engagement tracked in outsource/
• At least one contractor deliverable fully accepted
• At the end, access removed and shared information handled
• Fixed payroll kept to a minimum

---

Teaching S6: three 2-hour sessions

Make the dashboard the backbone. Running this three times taught us:

• “Database” is too abstract for people who’ve never used one; a lecture doesn’t land. The moment their own data appears on a screen, scattered vs. organized data clicks. (After the first session, we needed an extra session just on databases — this is why.)
• Parts 3–9 land far better as “add this field to your dashboard” than as law or theory.
• The most learning happens when participants show each other their screens. The more different the businesses — a tutoring school, property sales, a bakery with bookings — the more “here’s how I’d do it” comes out. Use the second half of each session for screen-sharing.

Session 1 (2h): where data lives and how it’s protected

• Covers: why now, Part 1, Part 2 (roles and decision rights)
• Goal: explain scattered vs. organized data, sensitivity, the three kinds of people data, the design sheet, and ids; understand how contract type changes management and Always / Ask first / Never
• Mini-work: build your own database and use it

Session 2 (2h): build the dashboard and take it outside

• Covers: the dashboard; Parts 3–9 as dashboard fields
• Goal: the build order, the three visibility levels, why money isn’t copied, starting work from buttons, and which field each Part adds
• Mini-work: get your dashboard onto your phone
• Homework: read Part 5 (acceptance), Part 8 (hiring), Part 9 (contracts and payments)

Session 3 (2h): turn it into the cockpit

• Covers: Part 4 (free-form reports, exceptions, handovers), Parts 6–7, Part 10 (customer screens); questions on the homework first
• Goal: why reports are free-form, exception-only design, why AI never evaluates, the factors in worker classification and written terms, and what may and may not appear on a customer’s screen
• Mini-work: build the company cockpit

Mini-work 1: build your own database and use it (20–30 min)

Pick one area where information is most scattered: inventory (inventory/, one item per file), business assets (assets/), or students/customers (customers/). Add five fields of your own to the four header fields (sensitivity, owner, updated, review): what it is, where it is now, what’s wrong, constraints, what’s next.

---
id: item-shipping-box-small
type: inventory
sensitivity: internal
owner: me
updated: 2026-10-12
review: 2027-01
---
Item: shipping box (small)
In stock: 320 (as of 2026-10-11)
Reorder when: below 100
Supplier: (path to the person file)
Next: decide November's order quantity

Set the sensitivity (for customers or students, fill the design sheet first — purpose, minimum fields, consent). Add only 3–5 records, by talking:

I'll describe my inventory one item at a time. Create one file per item in inventory/ in the format above. Ask me if a field is missing.

Then use it: “list items below their reorder point,” “list files not updated in three months,” “suggest next month’s orders with reasons — I decide.” Finally, write one line on who updates it, when, and on what trigger. A database with no update owner dies within weeks. Share: what you chose, how you set sensitivity, what you can now ask.

Mini-work 2: get your dashboard onto your phone (40–60 min)

1. Decide what you want to see, in one sentence. Pick something where past actions are already recorded (“did every class happen as scheduled?”, “how far along is each deal?”, “this week’s bookings vs. production”)
2. Have the agent build it — no detailed spec at first: “read projects/ (or inventory/, customers/) and build a one-page dashboard showing what’s moving and what’s stalled”
3. Use it 2–3 times and fix it — send screenshots: “the first screen is missing X,” “I never look at this field.” Fix the instructions and data, not the screen
4. Decide who can see it using the three-level table
5. If it goes on the web: protect → publish → check. On Cloudflare Pages, allow only your Google account with Cloudflare Access first; after publishing, open it in a private/incognito window and confirm you can’t see the contents. Opening it on your phone completes the exercise

Share: what you wanted to see, the first screen vs. the fixed one, how you decided who could see it.

Mini-work 3: build the company cockpit (40–60 min)

One screen that shows the company and how AI, freelancers, and partners are doing. The full template is in the business dashboard template (Japanese, with a visual sample for a fictional one-person company). Start from your own questions, not the sample.

1. Three questions the screen must answer — “which businesses are moving and which have stalled?”, “when did each AI and freelancer last report?”, “are customers growing or shrinking?” (traffic, sign-ups, inquiries, clicks)
2. Keep the source data in files and read everything from them — never retype numbers onto the screen (the template’s folder layout works as is)
3. Choose 2–4 moving numbers per business — numbers that come from outside and change weekly. Specs (“we have 16 products”) don’t move, so they don’t belong. Show current value + change vs. last week + a 12-week trend
4. Decide where reports go and how often — each report adds one file to reports/; weekly means 7 days is the threshold
5. Have the AI build it from the sample, adapted to your data, read-only, phone-width, “not available” for unreadable numbers and “no record” for missing ones — never guesses
6. Look, then fix — can the first screen alone answer your three questions? If not, fix the data or instructions and regenerate
7. Protect before publishing — as in mini-work 2. Get people’s consent before showing their photos or real names

Start with these design rules (the template has all 16):

• Put each business’s status, moving numbers, and last update on the first screen
• Your list shows only items where the ball is in your court. No scores or rankings of people
• Every number has a source and a date; “not available” rather than a guess
• The screen is a generated, read-only output — fix the source and regenerate
• Money and pay figures are read from finance/, never copied

Share: your three questions, the moving numbers you chose, and what you couldn’t see — and what surprised you once you could.

---

Related skills

• Before this → S5: Build your money data
• Builds on → S1: Build your own information system (people/ and the header block start there)
• The model → Business dashboard template (Japanese)
• Next → S7: Build an AI-centered team (Japanese) — combining small projects into an organization

---

SOVREN Framework is open-source. The English edition covers S1–S6; S7–S9 and the milestones are published in Japanese. Nothing here is legal, tax, or employment advice — confirm with qualified professionals where you operate.