Evidence-gated intake · preservation first · generated public queue

SISO agent capability discovery and promotion

This program continuously turns useful local agent mechanisms into owned, sanitized, verified, released, Library-indexed, and stack-pinned capabilities. It exists to preserve proven work without turning every interesting folder into a repository.

The operating problem

SISO already has valuable agent infrastructure distributed across released Works, source warehouses, operating workspaces, experiments, and host configuration. The gap is not invention. The gap is a dependable metabolism that can recognize value, establish evidence and ownership, extract the reusable mechanism, and finish publication without leaking private state or duplicating an existing Work.

working local mechanism
  → read and evidenced
  → classified and assigned
  → sanitized and extracted
  → tested and released
  → Great Library Work/Release
  → selected Snapshot
  → pinned Agent Stack component

Ownership boundary

SISO Foundry

Owns scalable source discovery, candidate comparison, fingerprints, reuse intelligence, and publication-safe candidate export. It never creates accepted Library Works automatically.

Great Library

Owns Source Inventory intake, evidence and rights review, stable Work identity, immutable Release evidence, Snapshot selection, and the public promotion projection.

Owning Agent Work

Hooks, Skills, Playbook, Runtime, Project OS, Agent Zero, Brain, Session Intelligence, Integrations, or another evidenced Work owns extraction, implementation, tests, and release cadence.

Agent Stack Distribution

Pins verified component releases into a reproducible installation. It does not absorb component identities or install promotion candidates.

Canonical lifecycle

Stage	Meaning	Required evidence to advance
`unverified`	A proxy or nomination only.	No consequential verdict or mutation is allowed.
`read`	The relevant source was read; the capability and uncertainty are described.	Dated source-review evidence and a preservation boundary.
`candidate`	Reusable value is plausible and does not duplicate a released mechanism as observed.	Content-based comparison, privacy and ownership risks named.
`owner_assigned`	An existing Work or justified new boundary owns the outcome.	Resolvable target Work and a concrete next gate.
`extracted`	Portable source has been separated from private state and host assumptions.	Clean source boundary, provenance, license, and fixtures.
`verified`	The owning repository proves the behavior.	Relevant tests, negative cases, installation checks, and independent verification.
`released`	An exact public source commit and immutable Release Manifest exist.	Commit-scoped artifact and distribution evidence.
`library_indexed`	The released capability is represented by its owning Work and selected Snapshot.	Schema-valid registry changes and full Library verification.
`stack_pinned`	The Agent Stack installs the exact verified release where appropriate.	A Stack Release carrying the exact manifest as a SHA-256-verified artifact, a component revision bound to the owning Release, Snapshot selection, and clean-install evidence.
`retired`	The candidate is explicitly closed without erasing its decision history.	Content-based reason and, when applicable, a successor reference.

A promotion stage is not a distribution claim. Only a Release Manifest can claim that source is downloadable, resolvable, installable, forkable, or portable.

The ten recurring loops

Canonical coverage: compare the active Works, Releases, Assembly, Snapshot, repository estate, and Stack manifest.
Discovery: inspect declared source roots while excluding secrets, client source, sessions, logs, databases, telemetry, raw personal memory, and private topology.
Classification: read before labeling; unresolved material stays unverified.
Capability delta: compare behavior and contracts rather than filenames or folder counts.
Ownership: assign the smallest correct existing Work; create a new Work only for independent outcome, adoption, ownership, release cadence, and verification.
Extraction: split generic policy and contracts from host adapters, credentials, personal paths, volatile state, and product assumptions.
Proof: add deterministic fixtures, negative cases, latency and privacy checks, failure recovery, and clean-install evidence.
Promotion: publish an exact owning-source commit and immutable Release Manifest.
Library and distribution: select the Release in a successor Snapshot and pin it into the Stack only when installation is appropriate.
Continuous archaeology: publish successor inventories, reopen changed decisions, and retain explicit rejection or retirement history.

Candidate assessment

Priority is a scheduling decision, not a truth score. Reviewers consider:

Value and use

Does the mechanism improve real agent outcomes, and is there evidence of a current consumer?

Portability

Can policy be separated from host, provider, personal paths, credentials, and topology?

Evidence

Are claims supported by direct source reads, executable checks, public commits, or dated receipts?

Fit and duplication

Does an existing Work already own the behavior? Is this a skill, hook, playbook, adapter, package, application, or genuinely independent Work?

Rights and safety

Are ownership, license, privacy, client boundaries, and publication rights explicit?

Machine contract

The accepted promotion queue is a dated immutable Source Inventory with publication-safe logical source scopes. Every unit records its classification, intended disposition, product-owner state and target Work IDs, evidence-owner Work IDs when ownership is unassigned, promotion stage, priority, confidence, portability, next gate, blockers, rationale, and dated evidence. An unassigned product owner cannot carry a target Work link or reach owner_assigned; this lets Foundry own candidate evidence without accidentally owning the future product. Raw laptop scans and private receipts remain outside the public repository.

The generated Promotion page and /promotion.json are projections over accepted inventory data. They never scan a contributor's machine during a Library build and never write Work, Release, Assembly, or Snapshot records automatically.

Repository-estate principle

Large GitHub storage headroom is useful for durable public source, immutable commit archives, releases, fixtures, and independently owned Works. It is not a reason to shard one system into thousands of repositories. Repository creation is earned by a coherent outcome, an owner, independent adoption, a release lifecycle, and a verification surface. Bulk data, generated corpora, operational databases, and private state remain behind explicit storage boundaries rather than being disguised as source repositories.

Completion contract

A campaign iteration is complete only when its accepted inventory is schema-valid, publication-safe, visible in the generated promotion surfaces, and accompanied by an exact next gate for every open unit. A promoted capability is complete only when its owning release, successor Snapshot, Stack decision, verification, deployment, and live receipt are recorded.

Registry model · Using the Library · Current promotion queue