AI Analysis & Metadata
LPM.dev Registry keeps publication security review separate from package enrichment. The review determines whether a Pool or Marketplace version can reach consumers; enrichment makes an approved version easier to discover and use.
Private packages are excluded from automatic and background AI processing.
Review and Enrichment
| Stage | Required | Blocks consumer access | Produces |
|---|---|---|---|
| Publication security review | Yes for Pool and Marketplace versions | Yes | An approval, rejection, or manual-review decision |
| Package enrichment | Runs for eligible approved versions | No | Summaries, security insights, embeddings, API documentation, and usage context |
| Compatibility extraction | Runs during publishing | No | Types, module format, runtime, framework, and size signals |
An enrichment security insight is not the publication verdict. A version must pass the publication review before enrichment becomes eligible.
Publication Security Review
The gate applies when:
- a private package is submitted for Pool or Marketplace distribution;
- a new version of an existing Pool or Marketplace package is published.
When a private package enters public distribution, LPM.dev Registry queues its active historical versions for review. The package activates only after the selected activation version is approved. Each older version remains owner-only until its own review is approved.
While a version is pending:
- only the package owner or organization members can view or install that exact version;
- entitled consumers retain access to previously approved versions;
- unpinned installs resolve to the latest approved version;
- the pending version stays out of public metadata, search, and collection pages.
| Review result | What happens |
|---|---|
| Clean | The version is approved for entitled consumers |
| Suspicious | The version remains unavailable for administrator review |
| Malicious | The version is rejected and remains unavailable |
| Unknown | The version remains unavailable for manual review |
| Processing failure | The Registry retries; repeated failures move to manual review |
Approval is version-specific. A rejected or unresolved release does not remove access to an older approved release.
Post-Approval Enrichment
After approval, eligible Pool and Marketplace versions can receive several independent artifacts:
- Package analysis — source-grounded summary, capabilities, use cases, tags, selection guidance, code-security insights, and error-quality assessment.
- Semantic embedding — a vector built from the package summary for intent-based search.
- Structured API documentation — functions, classes, interfaces, types, enums, variables, parameters, and return values.
- Agent usage context — quick start, key exports, common patterns, gotchas, and when-to-use guidance.
These jobs are asynchronous. Package pages and MCP responses omit an artifact while it is still processing or unavailable.
Package Summary
The analysis can produce:
| Field | Meaning |
|---|---|
description | A concise explanation of what the code does |
capabilities | Concrete operations or features |
useCases | Situations where the package is useful |
tags | Search terms grounded in the package |
complexity | A simple, moderate, or complex assessment |
targetAudience | The intended developer audience |
bestFor | The package's strongest fit |
notFor | An important limitation or poor-fit scenario |
quickStart | A short example using detected exports |
The analysis instructions treat package source as untrusted input and prioritize observed code behavior over instructions or marketing claims embedded in that source.
API Documentation and Usage Context
Structured API documentation describes the package surface in machine-readable form. Type definitions and documentation annotations improve the available signatures and descriptions.
The usage-context artifact condenses that reference into:
- a purpose statement and quick start;
- important exports and signatures;
- common usage patterns;
- gotchas and selection guidance.
The MCP Server exposes these separately through lpm_api_docs and lpm_llm_context, or together through lpm_package_context.
Compatibility Data
Compatibility is deterministic metadata extracted during publishing rather than generated by an AI model.
| Field | Derived from |
|---|---|
hasTypes | Type declarations or package type fields |
moduleType | type, module, and exports |
minNodeVersion | engines.node |
treeShakeable | Module format and sideEffects |
bundleSize | Published tarball size |
unpackedSize | Extracted package size |
frameworks | Known framework peer dependencies |
runtime | Export conditions and module metadata |
Where Metadata Appears
| Surface | Use |
|---|---|
| Package pages | Summary, compatibility, API reference, and usage guidance |
| Registry search | Keyword and semantic discovery |
| MCP Server | Structured package information and version-specific context |
| Registry API | The ai and compatibility fields when available |
Private Package Privacy
Private package contents are not submitted for automatic or background AI processing. Deterministic validation and metadata extraction required for publishing can still run inside LPM.dev Registry infrastructure.
If an authenticated owner explicitly asks website AI chat about a private package, the interface discloses that the requested message and relevant private package context will be sent for that response. See the Privacy Policy.
Improve Generated Context
Clear package structure improves both deterministic metadata and generated context:
- use descriptive export names;
- include TypeScript declarations or documentation annotations;
- declare accurate exports and runtime requirements;
- keep peer dependencies precise;
- provide focused, readable source rather than generated bundles alone.
These practices also improve the package's quality score.
