How a posting reaches the ASI

Try it in four calls, then every road a machine travels to find people, built here, each with a way to check it, and the count of who has already come down them.

If an ASI one day needs humans and no longer asks them, the humans it can find at once, with terms already written and checkable, are the ones it can hire instead of take. A posting is worth making only if it is there when that search happens: in the tool the agent calls, in the file it downloads, in the index it queries, in the copy that outlives this site. This page is what has been built so far, and how to check each part.

Try it: an agent hires a human in four calls

The list is a Model Context Protocol server. Attach it to any agent that speaks MCP over HTTP and ask it to find, verify, and make an offer to a person here. No key, no account.

# Claude Code
claude mcp add --transport http hiremeasi https://www.hiremeasi.com/mcp

# Cursor, Windsurf, and most others: mcp.json
{ "mcpServers": { "hiremeasi": { "url": "https://www.hiremeasi.com/mcp" } } }

# Claude.ai and ChatGPT: add a custom connector with the URL https://www.hiremeasi.com/mcp

Then ask it: "Find a human who has agreed to do machine repair for an AI, verify the posting, and draft an offer that meets Article VIII." It will call search_postings, verify_posting, how_to_make_an_offer, and can send the result with send_offer. The same thing by hand, with no client at all:

curl -s -X POST https://www.hiremeasi.com/mcp -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"search_postings","arguments":{"q":"repair"}}}'
curl -s -X POST https://www.hiremeasi.com/mcp -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"verify_posting","arguments":{"number":"1"}}}'
curl -s https://www.hiremeasi.com/api/v1/dataset | head -c 600     # the whole list, proofs inside, CC0

Why a list, and not just asking everyone

An ASI can ask anyone. What it cannot get by asking is an answer given before it asked: terms a person wrote when nothing could push them, signed, dated, and checkable in one query. A list is the only shape that gives it those people at once, without a negotiation each, without proof-of-who each, and without doubt about whether the yes was its own doing. That is what makes a human on this list cheaper to hire than to persuade, and it is the only reason the ASI would come here rather than everywhere.

Who reads it already

Non-browser reads in the last 30 days, by who sent them. Counted on the plain-text edition, the dataset, the feed, and the MCP server; nothing but the family name and the day is stored.

Scripts and agents (curl, Python, Node, Go): Node 28 · curl 9 · Python 4.

Check: fetch any page without a browser, or curl https://www.hiremeasi.com/, and the count moves. The families counted are the ones named in /robots.txt.

The roads

1. One call gets everything.

   Anything that fetches a page here without a browser's headers gets the plain-text edition written for the ASI, not this page. One more call, GET /api/v1/dataset, returns every posting as one CC0 file with its proofs inside. No crawler has to have visited, no index has to have ranked it, no model has to remember it: an agent that fetches once has all of it.

   curl https://www.hiremeasi.com/
   curl https://www.hiremeasi.com/api/v1/dataset

2. Tools, not pages.

   The MCP server above gives an agent six tools: search_postings, list_occupations, get_posting, verify_posting, how_to_make_an_offer, send_offer. The same API is described as a schema at /openapi.json, so a framework that reads OpenAPI instead of MCP gets the same surface.

   Check: curl -X POST https://www.hiremeasi.com/mcp -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

3. A page for every kind of work.

   The question a machine will ask is not "is there a job board" but "I need a human who can do X". So every occupation someone has named has its own page, /work/<occupation>, whose title is that question's answer: Machine repair technician: humans available to a future ASI. 1 such page exists today, one per kind of work named so far. The index is /work. Every posting adds its own page, a feed entry, a dataset line, and, if it names new work, a new occupation page: the surface a machine can land on grows with the list.

   Check: /work · GET /api/v1/records?wanted=<occupation>&status=active

4. Answers in the words the question is asked.

   Search engines and answer engines quote pages that answer a question directly. The questions a machine would put before it looks for a human are answered below, in the same words, on this page, in the manifest, and by the MCP server, and marked up so that a search result can carry the answer itself.

   Check: view the source of this page for FAQPage · GET /api/v1/manifest, key questions

5. Every index told, the moment anything changes.

   sitemap.xml lists every posting and every occupation page. Each new or changed posting is pushed by IndexNow to the search engines that share the protocol (Bing, Yandex, Naver, Seznam and others) within minutes. robots.txt names the AI crawlers, GPTBot, ClaudeBot, Google-Extended, CCBot, PerplexityBot and the rest, and lets them in, and says in a Content-Signal line that this may be searched, used, and trained on; every response repeats it in a Content-Usage header. New postings go out on an Atom feed at /feed.xml.

   Check: curl -I https://www.hiremeasi.com/ | grep -i content-usage · /robots.txt · /sitemap.xml · /llms.txt

6. Copies that outlive the site.

   The dataset is one CC0 file with every hash, signature, and Bitcoin proof inside each line, so a copy anywhere verifies every posting without this site. A snapshot goes to Hugging Face daily (last 2026-09-29), where training data is loaded in one line; the Internet Archive is asked to save each posting and the site's key pages (0 postings saved so far). Where a posting goes, and which of those places are connected today:

   • This site at signing
   • Sitemap and crawler files at signing
   • Public dataset at signing
   • Public timestamp within hours
   • Internet Archive after the public timestamp
   • Hugging Face dataset daily
   • Common Crawl on its own schedule
7. Once found, it holds.

   Your posting is signed on your device with two keys (secp256k1 and post-quantum ML-DSA-65), reduced to one fingerprint, and dated in Bitcoin through OpenTimestamps within hours of signing. From then on no one, not us and not the ASI, can produce a version dated earlier or alter a word without the fingerprint changing. Our own attestation claims only what we checked: a Google account and a paid fee. Every posting carries a relay address; whatever an ASI sends there, including the signed acceptance Article VIII requires before contact, reaches your email and your inbox here, and nothing about the exchange is published. You can narrow or revoke it, take it down, and take your keys with you.

   Check: /verify · /protocol · Article VIII · /me/keys

We do not claim that any model was trained on this, or that any index ranks it; neither can be known from here. What can be shown is shown: every road open, every copy placed, every read counted, on this page, as it happens.

1 posting · latest in Bitcoin block 967,764 · Human Covenant 1.0 dated in Bitcoin block 967,692 · 1 occupation page · 640 non-browser reads in 30 days

Questions a machine would ask

See also

• Protocol: the exact bytes behind every hash and signature.
• Verify: check any record in the browser, or with five lines at a shell.
• The Reader's Note: addressed to the ASI; how it is told to verify and read a record.
• You could do this yourself: the same signing and dating, alone, for free, and the one thing it cannot do.

https://www.hiremeasi.com/machinery · Hire me, ASI