Packs And Trust

Closed app stores curate by gate-keeping. The user gets a small, vendor-audited set of capabilities and no real way to extend the platform without writing a fork. Stallari is open by design: third parties ship capability through a pack ecosystem, and the substrate makes that openness safe through a trust chain rather than a curated list.

What A Pack Is

A pack is a bundle of capability declared by a YAML manifest. The manifest tells the platform what the pack ships: skills, workflows, plugins, transforms, operators, agents, tunables. The runtime reads the manifest, validates it against the pack-spec schema, and registers what the pack provides.

Surface a pack can ship	What it does
Skills	Named pieces of work the user can dispatch — “draft a reply to a thread”, “summarise overnight mail”.
Workflows	Composed graphs of skills with typed I/O contracts.
Plugins	MCP servers the pack registers as tools for skills to call. Sealed packs declare dependencies on Groupthink-Dev-authored blades; community packs may also ship their own community MCP plugins.
Transforms	Per-domain shims for ingesting external content into typed contracts.
Operators	Long-running roles (Chief of Staff, scheduler, comms operator, PKM operator) that pack authors can extend but cannot shadow. Extend means a pack can ship new skills or capabilities scoped to an existing operator’s role. Cannot shadow means a pack cannot replace an operator’s identity, fork its role, or register a competing operator under the same name — the platform owns the operator namespace so user-facing operator names stay stable as packs come and go.
Tunables	Schema-driven configuration the user can edit in the app.
Agents	Persona declarations with prompt, tool surface, and tier.

Pack authoring uses the same substrate the platform uses internally. There is no “first-party magic” — Stallari’s own behaviour ships as packs against the same spec community authors target.

Trust Tiers

Every pack carries a trust tier. The tier determines what the runtime allows the pack to do by default.

Tier	Signing	Default capability	Source
Sealed	First-party signed by Stallari.	Full default surface; can declare any capability subject to user consent.	Core platform packs.
Certified	Third-party notarised plus a Stallari capability-audit attestation; binaries pinned to a Team ID.	Audited capability set treated as declared-and-verified; user consent surfaces still apply for sensitive operations, with reduced friction.	Marketplace, badged.
Community	Third-party notarised plus Stallari-catalog-signed; binaries pinned to a Team ID.	User consent required per capability; capability set capped at pack-spec definitions.	Marketplace.
User	Self-signed by the user.	Quarantined on first install; broadest capabilities require user-supplied consent.	User authored, sideloaded, or shared peer-to-peer.
Imported	Unsigned or unrecognised.	Quarantine flow; four-action user decision before any code runs.	Sideloaded from arbitrary sources.

Tier affects defaults, not ceilings. A community pack that declares a sensitive capability still needs explicit user consent on first call. A sealed pack still runs under the same dispatch authoriser as everything else. The platform does not have a back-door for its own packs.

The Certified tier sits between Sealed and Community: the pack is authored outside Stallari but has been through the platform’s capability audit. The audit covers what the pack declares against what its tools actually do — including the granularity dimensions the Scope and ACL and Legibility and continuity layers rely on: scope-filter awareness in the plugin’s own API, per-field projection, deterministic result ordering, and audit fidelity (the plugin’s ability to disclose what it filtered server-side, not just what it returned). Community packs ship without that attestation — they honor the integrity-hash and capability-scoping mechanisms above, but the platform doesn’t vouch that their declared capabilities match observed behaviour. A community pack can be perfectly well-behaved; the user takes on the verification job rather than delegating it to the audit.

Integrity Hashes

The registry computes a content hash over every pack at publish time. The hash covers the manifest, the skill bodies, the workflow definitions, the transforms — everything the runtime executes. The hash is signed and published alongside the pack.

On install, the runtime fetches the pack and verifies the hash against the registry’s signed value. On every subsequent load, the runtime re-verifies. A pack whose hash does not match the registry’s signed value does not load. This is tamper-detection that holds even for unsealed packs — community and user packs benefit from the same integrity guarantee that sealed packs get.

Hash mismatch is not a silent failure. The Status surface names the offending pack, the expected hash, the observed hash, and the recovery action (reinstall, contact author, remove). The user is told and the platform stops before the pack can run.

Quarantine On Import

An imported pack with no recognised signature triggers the quarantine flow. The pack lands on a review surface with four explicit user actions:

Inspect — open the pack contents in the platform’s source-readable view. See what skills it declares, what tools it requests, what scopes it operates on.
Sign locally — promote the pack to user-tier by signing it with the user’s own key. The pack is now permitted but still capability-gated.
Reject — delete the pack contents and do not load it.
Defer — keep the pack quarantined; do not load it, but do not delete it either. The user can revisit.

Until the user takes one of these actions, the pack does not run. There is no auto-promotion, no implicit trust, no “probably fine because everyone else is using it”.

For packs that come from the community marketplace, the secops-scanner runs additional checks: declared capability inventory, network endpoint reachability, file system access patterns. The scanner’s verdict is surfaced alongside the pack in the marketplace UI.

Capability Scoping

A pack’s manifest declares the capabilities it requires. The runtime treats this declaration as a contract: the pack is permitted to use exactly the capabilities it declared, never more.

Scope names are not platform-fixed. They are user-curated tunables — your work is another user’s consulting, client-projects, or paid-engagements. A pack does not name your specific scope vocabulary in its manifest. Instead, the manifest declares scope requirements in semantic terms (“a scope the user designates as billing-related”), and at install time the user binds the requirement to one or more scopes in their own vocabulary. From the bind point forward, the pack is locked to the bound scope set.

Concretely: a pack that asks for “a scope the user designates as billing-related” might be bound at install to the user’s work scope, or to a dedicated bizops scope, or to both. Once bound, the pack can read mail tagged with the bound scope only — anything tagged family, personal, or any user-named scope the pack was not bound to is invisible to it, no matter how the model wrapped inside the pack might be cajoled. A pack that declares “write to vault notes” cannot send mail. A pack that declares “call network endpoints api.example.com” cannot call any other endpoint.

This is the same tool-surface scoping mechanism that gates first-party skills. Packs do not get a special enlarged surface. They run under the same authoriser. The user grants capability at install (broad consent + scope binding) and per-call at dispatch (specific scope, specific data).

Adapters And Transforms

The pack ecosystem solves the perennial integration problem differently from connector marketplaces. Most platforms ship a fixed set of provider connectors and let pack authors call them. Stallari ships an adapter framework: the platform owns the canonical contracts (mail-thread, calendar-event, file-resource), and authors write transforms that shim a specific provider into the canonical shape.

A user who needs Gmail support installs the Gmail transform pack. The transform reads the user’s Gmail account through its API, normalises threads into the canonical mail-thread contract, and feeds them into every skill that consumes mail-thread — first-party or community. The user does not need to install a “Gmail skill”, a “Gmail digest skill”, a “Gmail classifier skill”, a “Gmail reply-drafter skill”. One transform makes Gmail visible to every mail consumer.

This is how community extension stays bounded. Authors write the small thing — the transform — that opens up the large thing — every existing consumer of the contract.

No Phone-Home For Packs Either

Packs run under the same outbound-call discipline as the rest of the platform. A pack cannot phone home to its author’s telemetry endpoint by default. Any outbound network call a pack makes must be declared in its manifest, scoped to a specific endpoint set, and authorised under the runtime authoriser.

This applies to local-corpus blades equally. A blade that reads the user’s mail to feed an on-device LLM does its work locally and reports nothing externally. The substrate filters blade tools off the platform’s HTTP MCP surface — even within the user’s own fleet — so a blade cannot leak data through a misconfigured tool surface.

The substrate is the user’s; it is not a vendor’s data collection chassis pretending to be a pack ecosystem.

Operations Catalog And Continuity

The Operations Catalog surfaces every operation a pack declares — first-party and community alike — in a Finder-style view. The user can browse packs by capability, see what each operation does, inspect its tunables, and dispatch it ad-hoc. This is the discovery surface for the pack ecosystem.

The continuity layer (stallari-precedent) crosses pack boundaries. When a pack’s skill makes a judgment call — picking a recipient, selecting a provider, choosing a classification — the precedent is recorded in the user’s vault. A future skill from a different pack can read the precedent and follow it. This is how the user’s accumulated taxonomy survives any single pack’s churn.

Agency model — how pack-shipped skills compose against typed workflow primitives.
Scope and ACL — how scope tags gate what packs see.
Legibility and continuity — how pack actions are auditable and precedent-recording.
Local vs cloud — how packs participate in provider routing without changing the routing policy.