Your AI workers live on individual laptops today — change the machine, the account or the model and everything they built up goes back to zero. fdelink brings them into the organization: one set of boundaries · approvals · audit, one conversation thread continued across 7 harnesses, with profile, memory, ledger and evaluations that belong to the organization instead of to a device.
web.read · doc.write — mail.send is outside the boundary, unavailable this round--resume 8f3a…, injecting identity · boundary · space memory · last 3 round summariesOne worker, moved between these harnesses without losing its memory
The models are fine; the container is wrong. Treat AI as a one-off call and every run starts from nothing. Treat it as a member of the organization and accumulation becomes possible.
Each one lands in the server and the execution layer — not in a UI label that says “governed”.
Threads are isolated by “harness @ execution identity”: switch account or device and a new thread is built; switch back and the old one is found again. We never force-resume another account's session. When hard continuity breaks, ledger summaries carry the context instead.
standby → running → idle → archived; archived ≠ deletedAny item can be promoted to a loop: each round the worker reports done / todos / gate / whether the goal is met, and maintains its own backlog. When a human call is needed it raises a gate into “waiting on you” — and if other work is available it does that instead of idling.
Every worker and every person holds an ed25519 identity, and each worker round is signed by the worker. Audit is written twice — a display table and an append-only signed chain where each entry carries the previous hash. Change any row in the database and verification names the break.
/api/chain/verify is open — don't trust us, checkPick ownership when syncing: run records in a personal space stay on local disk and the cloud keeps only an index and summaries; team spaces sync in full. The same worker can switch “follow / keep local / to cloud” per round.
Skills and MCP configuration are scanned from the actual machine and synced up; for credentials only the environment-variable key name is recorded — values never reach the database. Connectors get one of three policies: unrestricted / read-only declaration / hard-blocked at execution, where a blocked connector's tools are physically removed at dispatch.
[high risk] in auditItems are generated out of real tasks: L1 assertions plus L2 review, with the reviewing harness kept separate from the executing one. Scoring on two harnesses gives attribution — a gap under the threshold means the bottleneck is the gene itself, and improvement suggestions are generated automatically.
Discovery and sync are the entrance, boundary and approval are the gate, ledger and evaluation are the return path — complete one turn and the organization owns an asset that depends on nobody's computer.
Bypass the UI, call the API directly, and you meet the same rules — that is the difference between governance and a UI that says “governed”. Every line below has a matching executable assertion; run them once and you know.
python3 scripts/verify-prd.py → 69 rule assertions
python3 scripts/e2e.py → 17 main flows, 60 checks
bun test → rule kernel and auth
| Role | Can | Cannot |
|---|---|---|
| member | assign / reply / hold a seat / waitlist | every management write (403) |
| tenant_admin | all governance within the tenant | — |
| platform_admin | operations: snapshots / stripping / tenant directory | business reads and writesegress redaction + 403 on business writes; permission rows can't be changed or deleted |
| space_lead | profile / level / memory / loops / retros for workers in the space | cross-space management (403) |
| external | replies only when @-mentioned | initiating anything (locked server-side) |
Even “who are you” is decided on the server. Roles are injected by the upstream gateway, but the injection has to be verifiable: the gateway HMAC-SHA256s “role · tenant · expiry” with a shared secret and the server recomputes it. Swapped role, swapped tenant, swapped key, expired — all four forgeries are rejected. In production a missing secret refuses startup; we don't serve on half a configuration.
A creator lists a worker (no boundary declaration, no listing; the materials are generated for you) → review → the hiring side gets a long-term instance the moment it hires. Three billing models, revenue accrued per real round.
Percentages are the creator's revenue share. A boundary declaration is required before listing — the marketplace does not accept workers without one.
One codebase, two stores: with no configuration it writes local JSON; with Supabase configured it uses the relational model and RLS.
Multi-stage build (front end compiled → the runtime image carries only artifacts and server source), runs as non-root, and tini forwards SIGTERM so a graceful shutdown actually receives the signal.
/api/health (never touches storage) · readiness /api/ready (actually touches it)Request-scoped multi-tenant isolation + database RLS. Personal-domain run records stay on the user's own disk while the cloud keeps only index and summaries, and for credentials only environment-variable key names are stored.
The portability ruling walks local harnesses, skills and connectors item by item and decides for each gap whether it can be auto-filled; one-click repair restores skills into local directories, and same-name-different-content is refused rather than overwritten.
No. Those are the harnesses; fdelink is the governance layer above them. Your people keep the CLI they like, and fdelink brings the workers running on those tools into the organization — giving them boundaries, keeping the ledger, running the evaluations, and carrying profile, memory and thread across when the harness changes.
Two layers. Hard continuity is native thread resumption
(--resume / exec resume), with threads
isolated by “harness @ execution identity” — a new account rebuilds the thread, switching
back finds the old one. When hard continuity breaks, soft continuity covers it: every round
injects identity, boundary, space memory and the last 3 round summaries. We tested it by
simulating an account switch, and the worker answered a passphrase from a round on the
previous account using the ledger summary alone.
The boundary is a server-side constraint, not a polite line in a prompt. Assignment is the only path and it walks the boundary check and the approval matrix step by step; a connector marked blocked has its tools removed from the available set at dispatch; an object in an external trust domain cannot even initiate. Calling the API directly meets the same decisions.
Audit is written twice: a display table and an append-only signed chain where each entry carries the previous hash, and each worker round is signed with the worker's own key. Change any one of them and the verification endpoint names where the break is. Verification is in your hands — you don't have to trust our word for it.
It depends on ownership. Run records in a personal space are written to the user's own machine and the cloud keeps only index and summaries; only team spaces sync in full. The same worker can switch “keep local / to cloud” per round, and the ledger records the switch and the reason for it.
Test items come from real tasks, not from public leaderboards. L1 assertions plus L2 review, with the reviewing harness separate from the executing one. The same items run on two harnesses: a gap under the threshold means the bottleneck is the worker's gene (prompt and configuration) rather than the model, and the system generates improvement suggestions from that. With only one harness sample, no attribution is made.
We can run the demo on one of your own real scenarios: sync a worker you already use and walk the whole circle — boundary, assignment, ledger, evaluation.