ATLAS/TRUST MODEL SHEET T / 01

Every blueprint is drafted, reviewed, and audited before it's shelved.

Agentic blueprints run with real permissions: reading files, calling APIs, executing shell commands. metafactory is built so that what you install is something a named human has already put their reputation behind. Six mechanics carry that weight.

◇ 01 · IDENTITY
Publishers are people

Every publisher on metafactory is a verified identity. No anonymous uploads, no ghost accounts, no disposable aliases. Five tiers (○ ◐ ● ◆ ★) make trust visible at a glance, and you can always trace a blueprint to a human you can read about.

IN PRACTICE
Before a new operator can publish their first blueprint, they enable MFA, link a GitHub account, and have their identity verified by someone already trusted on the shelf. The receipt is permanent: every blueprint they draft forever carries their name.
◇ 02 · SPONSORSHIP
New names are vouched for

A first blueprint from an unknown operator never ships alone. A named sponsor, someone already trusted on the shelf, has read the code, checked the capability declarations, and put their own reputation behind the submission.

IN PRACTICE
When you look at a freshly shelved blueprint from a New publisher, you see two names: the author, and the sponsor who signed off. If the blueprint turns out to be trouble, the sponsor's tier is affected. That's the incentive that keeps review honest.
◇ 03 · CAPABILITIES
Every power is declared

Filesystem, shell, network, secrets, subagents: every capability a blueprint needs is listed in its manifest, justified by the steward in plain language, and surfaced in a full-width audit panel on the blueprint's page. No hidden access.

IN PRACTICE
Every blueprint lists exactly what it can access: your files, your terminal, network connections. If a new version asks for more access than before, the change is visible and the publisher must explain why. You always see what changed before you install.
◇ 04 · TAMPER EVIDENCE
Every release is sealed

Every release is content-addressed — like a wax seal on a letter. The fingerprint is computed at publish time, stored in the registry, and displayed on the blueprint page. If the seal is broken, arc refuses to install.

IN PRACTICE
A content fingerprint is tamper evidence, not a safety attestation. It tells you nothing moved behind the steward's back — not that the code is correct. Trust still comes from identity and sponsorship; the seal is the receipt that guarantees you got the bytes that were reviewed.
◇ 05 · REGISTRY SIGNATURE
The fingerprint list is signed

Every release index is signed by metafactory — like a letterhead on the envelope that holds the sealed letters. When arc fetches the index, it verifies the signature against a key it already knows. A compromised mirror or man-in-the-middle can't slip a fingerprint into the list.

IN PRACTICE
Tamper evidence (◇ 04) tells you the bytes didn't change. A registry signature tells you the list of fingerprints didn't change either. Without it, an attacker who controls the index controls what you trust. The signature closes that gap.
◇ 06 · PUBLISHER PROVENANCE
Proof of who built it

Each published release carries a cryptographic attestation tied to the author's identity, recorded in a public transparency log. You can verify not just that metafactory approved a release, but that a specific person built it — and even we can't rewrite the record.

IN PRACTICE
Registry signatures (◇ 05) prove metafactory vouched for a release. Publisher provenance proves who wrote it, independently. If metafactory's signing key were ever compromised, the transparency log still holds — it's a second opinion that doesn't trust us.
· VERIFICATION TIERS ·

Trust is earned, five tiers at a time.

Every publisher starts at New. Each tier unlocks new capabilities and responsibilities. Progression requires sustained, verifiable contributions and human review at every step.

New
TIER 0

Can browse and install. Submissions require full sponsor review. An explicit "not verified" warning is shown.

✓ Browse the atlas
✓ Install blueprints
⚠ "Not verified" warning
Identified
TIER 1

Identity confirmed. MFA enabled, GitHub account linked, verified by an existing trusted member.

✓ MFA enabled (required)
✓ GitHub identity linked
✓ Verified by a member
✓ Sponsor reviews submissions
Proven
TIER 2

Track record established through sustained contributions. Can review other publishers' work.

✓ 3+ published blueprints
✓ Sustained contributions
✓ Can review others
✓ Community standing
Trusted
TIER 3

Security-aware operator who can sponsor new contributors into the ecosystem.

✓ 5+ published blueprints
✓ Security awareness
✓ Can sponsor new publishers
✓ Attestation authority
Steward
TIER 4

Governance authority. Promotes operators, coordinates security response, shapes ecosystem policy.

✓ Governance authority
✓ Promotes other operators
✓ Security coordination
✓ Ecosystem stewardship
MFA is a hard gate

No MFA, no badge. Multi-factor authentication is required before any tier beyond New. Hardware keys are recommended for Trusted and above.

THE SPONSOR MODEL

No one publishes alone. Every new contributor needs a sponsor who has read the code and put their reputation behind it.

1
Submit
New publisher creates a blueprint and submits for review
2
Review
Sponsor reads code, checks capabilities, and assesses security
3
Vouch
Sponsor signs off with their name and reputation attached
4
Shelved
Blueprint goes live with both names visible to everyone
WHAT THIS IS NOT

metafactory is not a sandbox, not a code audit service, and not a guarantee of correctness. It is an identity-anchored trust network: blueprints come from named people, are vouched for by other named people, declare what they do, and are addressed by their contents. The six mechanics above are the whole trust model. Everything else on this site is a consequence.

Cryptographic signing → Blueprint lifecycle → Author journey →
THE BLUEPRINT LIFECYCLE

Ten stages of trust

Every blueprint passes through ten stages — from the author's first arc bundle to the consumer's arc install. Each stage has an owner, a gate, and a design decision that anchors it.

01
Author
JOURNEY →
02
Bundle
03
Publisher sign
SIGNING →
04
Handover
SEAM →
05
Attribute gate
GATE →
06
Clean room
ROOM →
07
Sponsor review
08
Registry sign
SIGNING →
09
Publish
10
Install + enforce
SEAM →
FULL LIFECYCLE → QUARANTINE INCIDENT RESPONSE