SpecPM
Submission Guide Add SpecPackage

Specification Registry + Need Resolution Engine

Resolve needs into specifications. Implementations come included.

SpecPM is building the need resolution engine for reusable specification intent. The package and registry layer is live now with exact intent.* metadata; the upcoming resolver will turn plain-text needs into reviewable SpecPackage and BoundarySpec candidates.

SpecPM v0.1.0 Build 149 Revision d075e67d3a8e Package Layer Live Intent Index Live Docker Local Service Live Need Resolution API Soon
Preview Intent API Read Docs Open Registry Viewer

Available now: validation, inspect, deterministic pack, local/public index, exact capability and intent lookup, observed intent catalog, SpecGraph inbox, and read-only registry metadata.

Intent Input - Coming Soon
I need enterprise authentication for a B2B SaaS dashboard.
Canonical Intent
intent.identity.enterprise_sso
Status
Live exact lookup
Candidate SpecPackage
auth.enterprise-sso
Preview Fit
98% candidate
Verified by SpecPM Today
  • SpecPackage validation
  • BoundarySpec inspection
  • Deterministic .specpm.tgz pack
  • Static /v0 + observed intents
  • First-class index.provides.intents
Boundary

The future resolver may propose candidates. SpecPM verifies exact package data, backed intent IDs, paths, provenance, and registry metadata.

Package Substrate First

A verifiable registry layer for specification intent.

Traditional package managers expose code first.

SpecPM works differently.

It stores specifications as the primary unit: structured, reusable definitions of what a module, subsystem, or product boundary should do. Today, SpecPM validates, packs, indexes, and exposes package data, capability IDs, backed intent.* IDs, and an observed intent catalog. The intent-to-spec resolver is the next online/API layer built on top.

The current layer makes specs verifiable.
The next layer makes intent resolvable.

The Problem

Plain text intent still needs a verified package layer.

The future resolver can turn a need into candidate specs. SpecPM makes those candidates reviewable by validating exact package structure, capability IDs, backed intent IDs, evidence, provenance, and registry metadata.

Current package-manager work removes the fragile parts first:

  1. 01Validate package shape.
  2. 02Inspect BoundarySpec intent.
  3. 03Pack deterministic archives.
  4. 04Index exact capabilities and intents.
  5. 05Expose static /v0 metadata.
  6. 06Let SpecGraph observe package visibility.
- Live now: exact package verification. - Soon: semantic intent-to-spec discovery. - Always: package content stays untrusted data.

Current Status

The package and registry substrate is working now.

SpecPM already provides the deterministic substrate that an intent-to-spec service needs: trusted outputs, exact capability lookup, exact intent.* lookup, observed intent catalog metadata, package validation, and read-only registry metadata.

Live

Local CLI package manager

  • validate and inspect SpecPackage directories
  • pack deterministic .specpm.tgz archives
  • diff package versions and report breaking changes
Live

Local and public registry metadata

  • index, search, add, lock, yank, and unyank locally
  • expose first-class index.provides.intents
  • publish observed intent catalog endpoints
  • generate static public /v0 registry files
  • serve the public index locally through Docker
Live

SpecGraph and viewer contracts

  • inspect SpecGraph inbox bundles
  • read remote registry status, packages, intent catalog, capability search, and intent search
  • publish DocC documentation and conformance fixtures
Soon

Intent-to-spec online API

  • accept plain-text product or engineering needs
  • propose exact SpecPackage and BoundarySpec candidates
  • use semantic discovery while keeping SpecPM core verifiable

How SpecPM Works

Package intent today. Resolve plain text soon.

01 / 04

Package reusable intent

Authors describe product and engineering boundaries as SpecPackage and BoundarySpec data with capabilities, requirements, evidence, provenance, and constraints.

02 / 04

Validate and pack

SpecPM validates restricted YAML, blocks path escapes, inspects package metadata, and creates deterministic archives without executing package content.

03 / 04

Index and expose

Packages become searchable by exact capability ID and backed intent.* ID through local indexes, generated public /v0 metadata, and read-only remote registry client commands.

04 / 04

Resolve intent soon

The upcoming online/API layer will map plain text needs to candidate packages. SpecPM will remain the exact verification layer under that resolver.

Registry Surface

Specification packages are the dependency layer.

Code dependencies tell you what you installed. Specification packages tell downstream tools what a boundary means, which capabilities and canonical intents it provides, what evidence supports it, and how it can be verified.

SpecPM already publishes static read-only registry metadata that SpecGraph, ContextBuilder, and other consumers can observe.

Open Registry Viewer Strict JSON Status
Intent → Capability → SpecPackage → Registry Metadata

Live Registry Building Blocks

SpecPackage

The package manifest, referenced BoundarySpecs, evidence, foreign inputs, metadata, compatibility, and first-class intent declarations.

BoundarySpec

Structured intent, scope, provided capabilities, capability-backed intentIds, interfaces, effects, and provenance.

Exact Search

Local and remote lookup by exact capability ID or canonical intent.* ID, with semantic discovery intentionally kept outside core.

Provider-neutral contracts

Define an abstract SpecPackage for a desired capability, then let downstream tools relate concrete provider packages through explicit evidence and governance.

Public /v0 Index

Live static registry status, package index, version metadata, capability search, intent search, and deterministic archives can be explored in the registry viewer.

Docker Service

A local static public-index service at localhost:8081 for SpecGraph, ContextBuilder, and manual integration testing.

DocC and Conformance

Published documentation, JSON contracts, golden fixtures, and self-spec validation for the public surface.

Public Index Intake

Add a SpecPackage to the public registry.

Anyone can propose a public SpecPackage repository. SpecPM validates the submitted package as untrusted data, comments with a pass/fail report, and leaves acceptance to maintainer review before the static /v0 registry is regenerated.

Add SpecPackage(s) Read Submission Guide
Requirements

What a submission needs

  • public HTTPS Git repository URL
  • specpm.yaml at repository root or a declared package path
  • referenced specs/*.spec.yaml files
  • passing specpm validate
  • stable package ID, SemVer version, and license metadata
  • package content that does not require execution during validation
Review Flow

How it reaches /v0

  1. Open the Add SpecPackage(s) issue form.
  2. List one or more public repository URLs.
  3. GitHub Actions validates each package and comments with evidence.
  4. Maintainers review the issue and accepted package source.
  5. A PR updates public-index/accepted-packages.yml.
  6. GitHub Pages republishes static registry metadata.

Built for Agents

Built for agents that need verified spec candidates.

SpecGraph and ContextBuilder can consume SpecPM packages as verified metadata today, including exact package-neutral intent.* IDs. The future resolver will add plain-text intent intake before that exact package verification step.

Agents can explore intent.
SpecPM verifies packages.

SpecGraph Agent

“I need enterprise-ready authentication for a SaaS product.”

Intent Resolver + SpecPM
Soon

Map plain text to intent.identity.enterprise_sso and candidate packages.

Live

Verify package shape, evidence, capability IDs, backed intent IDs, and registry metadata before selection.

Why SpecPM Is Different

From package files to intent-aware discovery.

Package managers expose implementation. SpecPM exposes verified specification intent through exact capabilities and first-class intent.* metadata. The upcoming resolver adds the semantic front door; the current CLI and registry keep the result machine-checkable.

Current SpecPM

  1. Validate package and BoundarySpec shape
  2. Inspect capabilities, evidence, and provenance
  3. Pack deterministic archives
  4. Index and search exact capability and intent IDs
  5. Expose static public registry metadata
  6. Let SpecGraph observe package visibility

Intent-to-Spec Soon

  1. Accept a plain-text product or engineering need
  2. Use semantic discovery to propose canonical intent.* IDs
  3. Return exact SpecPackage and BoundarySpec references
  4. Mark candidates as reviewable, not automatically trusted
  5. Verify every candidate through SpecPM metadata

Intent-to-Spec API Coming Soon

Built for humans, agents, and downstream tools.

The hosted resolver will accept plain-text intent and return exact, reviewable package candidates. The local CLI already provides exact capability lookup, exact intent lookup, and the registry substrate behind that flow. 

# coming soon: hosted intent-to-spec API
POST /v0/resolve-intent
{
  "intent": "enterprise authentication for B2B SaaS",
  "context": "SpecGraph product boundary"
}

candidate:
  intent: intent.identity.enterprise_sso
  package: auth.enterprise-sso
  status: review_required

# available today: exact verification layer
$ specpm validate examples/email_tools --json
$ specpm inspect examples/email_tools --json
$ specpm search-intent intent.document_conversion.email_to_markdown --json
$ specpm public-index generate --manifest public-index/accepted-packages.yml --json

Current CLI, Future Resolver

Use the package substrate now. Resolve plain text soon.

Start with validated SpecPackages today. The online intent-to-spec layer will turn user needs into reviewable candidates on top of the same registry contract.

Read Docs RFC on GitHub