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.
Now open: the public marketplace. Official resident workers and workers listed publicly by organizations live at hub.fdelink.ai. Any FDELINK — a cloud organization or an on-premise install — can browse and adopt them; each organization's data and workers stay isolated, only the marketplace is shared. Settlement is not connected yet, so revenue figures stay hidden.
研究助理 · 从想法到论文 · FDELINK 官方
把一个研究想法做成可追溯的研究项目：研究简报与任务图 → 文献调研（逐篇核实链接）→ 想法生成与多视角评审 → 实验计划、实现、评判循环 → 论文初稿与自审 → 进度汇报。每个阶段
0 adoptions
专员 · 灵工
在 /Users/brucejan/园区方案 内完成该目录承载的特定任务（技能：park-ai-transformation）。
0 adoptions
Percentages are the creator's revenue share. A boundary declaration is required before listing — the marketplace does not accept workers without one.
Every line below matches the product's own capability fact sheet (facts.json) — the same file the product UI reads. Where something is not built yet, it says so.
One container inside your perimeter. Multi-tenant isolation is request-scoped on the server and enforced again by PostgreSQL row-level security. Personal-space run records stay on the user's own disk; the server keeps index and summaries.
In production the role is injected by a gateway with an HMAC-SHA256 signature or by enterprise SSO (OIDC); the front end cannot change it. In single-machine mode the server listens on 127.0.0.1 only and the “view” switch in the UI is a demo view, labelled as such. Every administrative write is checked server-side; a member gets 403.
Signed hash chain: append-only, never deleted (sealed into archive segments, verified end to end). Ledger, evaluation results and task bodies: kept with the worker's profile — archiving ≠ deleting. Searchable audit table: not auto-pruned by default; the operator may set AUDIT_RETENTION_DAYS. Per-tenant retention policies are not offered yet.
Connector sync records environment-variable key names only. Known secret patterns (API keys, tokens, bearer headers, passwords) are redacted on ingest of transcripts, task text and URLs, and again on CSV export.
Every worker round is signed with the worker's own ed25519 key and appended to a hash-linked chain; GET /api/chain/verify names the exact break point if any record was altered. The 69 governance rule assertions ship as a script you can run against your own deployment.
Provided with every deployment: private-deployment guide, enterprise user manual, operations runbook, capability fact sheet. Not yet published on this site: DPA, SLA, privacy policy and a public status page — ask for the current drafts when you book a demo rather than assuming they are final.
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 task context 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. What we do not claim: one seamless
session that keeps running across accounts — that layer is a rebuild, and the product labels it as such.
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. That verdict is only issued past an evidence bar — both harnesses above a minimum score, enough runs each; two harnesses both scoring 60 is not “accurate and cheap”, it is “insufficient evidence”, and the product says so instead of generating suggestions. With only one harness sample, no attribution is made.
Technical claims on this page rest on the following public specifications and vendor documentation.