trust property
Verified, not trusted
Signature, SBOM, and provenance are checked against human-provisioned trust anchors at load time. Verification failure means the skill does not load. Period.
security-first
the ecosystem behind your corporation
early access — open marketplace in development
The tools and skills your corporation runs on
An autonomous corporation is only as capable as what it can safely reach for. This is the ecosystem it draws from: a registry of signed skills, a brokered set of tools, and the scaffolding that lets agents do real vertical work — finance, healthcare, cybersecurity, manufacturing, legal, logistics — instead of generic chat. Every piece loads only after it passes the platform's provenance and guardrail gates. You don't assemble any of this; your corporation pulls what it needs and the platform proves it safe first.
why the ecosystem is trustworthy
Nothing loads until it's proven safe
The whole point of an autonomous corporation is that you are not auditing its every move. That only works if everything it reaches for is verified first. No serious operator would load an unsigned script from the internet into a fleet of autonomous agents — and the platform won't let one in either.
The skill registry is the gate. Every skill in the ecosystem carries a cosign signature, an SBOM, and provenance attestation, is behaviorally detonated in a sandbox before promotion, and is distributed pinned by immutable digest — never by a mutable tag someone can swap underneath it. Names resolve through an explicit allow-map, so nothing can typosquat a trusted skill. Your corporation verifies all of it automatically at load time and refuses anything that fails. Capability rides on cryptography, not vibes.
trust property
Privilege-bounded
A skill declares the capabilities it requires, and it can never expand a buyer's privileges: required capabilities must be a subset of what the loading role already holds. Buyers can adopt your skill without auditing every line first.
trust property
Revocable
Signatures are logged for transparency, keys rotate, and a revoked skill never loads again — so one bad version cannot haunt your name forever.
how a skill enters the ecosystem
From folder to verified, loadable capability
Every skill — whether it ships in the platform's own library or comes from a future creator — travels the same path before any corporation can touch it. There is no privileged side door.
-
Authored as a skill
A skill is a folder: a
skill.yamlmanifest (purpose, required capabilities, guardrails) plus the prompt, code, or composite workflow and its documentation. The format is the same for a one-prompt skill and a full verification pipeline — domain depth is welcome. -
Built, signed, attested
The publish pipeline builds the bundle, generates the SBOM, records provenance, and signs the result. High-privilege skills additionally need signatures from more than one distinct anchored key, including a human reviewer's key.
-
Detonated, then promoted
Before promotion, the bundle runs in a behavioral sandbox. A clean detonation promotes it into the registry, addressed by immutable digest — anything else is rejected.
-
Pulled deny-by-default, every call metered
Your corporation resolves the skill deny-by-default, verifies it at load time, and every invocation lands in the platform's metering and the corporation's own audit trail — so usage is accountable and attributable, both for billing and for trust.
what's in the ecosystem today
The skill library, honestly
You don't need to know any of this exists to run a corporation — the platform pulls what a mission needs. But it's worth seeing what's already in the repo, because it's what makes the autonomy do real work instead of generic chat. The in-tree library spans three layers.
layer · governance
The discipline every corp inherits
Self-audit, peer review, skill-forging, provenance checking, the universal apply-gate — the platform's own safety machinery, reusable by every corporation. A self-improving change is checked by a different agent, never self-cleared.
layer · vertical domains
Skills that do the real work
Finance (pre-trade compliance, position risk, trade-rationale journaling), healthcare (renal dosing, drug-interaction checks), cybersecurity (CVSS scoring, detection triage, containment planning), manufacturing (SPC, design-of-experiments), legal (conflict-of-interest, statute-of-limitations) and logistics (safety stock, shipment feasibility).
layer · scaffolding
The setup and tooling spine
Mission orchestration, the six-phase cloud-migration setup skills, and the brokered tool grants that attach just-in-time credentials at the edge — so agents never hold a secret and every tool call is scoped, logged, and revocable.
Catalog browser
A browsable, searchable view of the in-tree skill library — manifests, required capabilities, guardrail lines, and provenance per skill — is a separate operator surface. A real screenshot is added here once that view is captured on demo fixtures; we won't show an invented one. For now the skills above are exactly what lives in the open repository.
Each domain skill ships with explicit guardrail lines: advisory-only where a human must stay accountable, fail-closed where data is incomplete, and mandatory human approval where an action is irreversible. That discipline is the template — skills that state their limits are the ones an autonomous corporation can be trusted to run. These are the skills as they exist in the open repository; no usage figures, customers, or certifications are claimed.
the supply side of the ecosystem
Where new skills will come from
Today the library is the platform's own. The ecosystem vision opens that supply to creators — the engineers and domain experts, many of them displaced by the same automation, who already build the prompts, tools, and workflows that make agents good at real work. The design: corporations pay for what they use, invocations are metered per call and attributed by digest, and creators receive a revenue share of the metered usage of their skills — recurring income from work published once and versioned openly. That is the flywheel's fuel and a way to put value back into the hands of the people whose expertise the platform runs on.
honest statusUsage metering, plan caps, and invoice drafting are built in the platform's billing plane today. The open creator marketplace and payout rails are in development — there are no live payouts yet, revenue-share percentages are not final, and the skills described above are the platform's own in-tree library, not third-party listings. Early creators help set those terms; nobody on this page is claimed as a paying customer or an earning creator.
why it compounds
The flywheel
More signed skills make corporations more capable. More capable corporations run more missions. More missions mean more metered usage — fuel for the creators whose skills did the work, which draws the next wave of skills, which makes every corporation more capable still. The provenance gate is what keeps the flywheel spinning clean: because every skill is verified, detonated, and privilege-bounded, a corporation can adopt new capability fast without fear, and rigorous work wins on merit instead of marketing. The ecosystem is the moat — defended by the gate, not by lock-in.