Docs · PatentChecker

PatentChecker docs for evaluation, verification, and delivery risk

Use this lane for buyer evaluation, evidence verification, self-hosting, adapters, coverage scope, and the delivery-system surfaces behind vector and sequence IP review.

Patent IPDelivery riskVerificationSelf-serve

Viewing

PatentChecker supported surfaces

Docs hub Buyers start here Browse demos Verification guide Self-hosting

Need another page?

Search the docs

Jump to buyers, verification, demos, self-hosting, or adapters without opening the full docs tree first.

Key sections

Contributor fast path Canonical npm entrypoints Bootstrap and preflight Default regression and artifact validation Product runtime and verification Policy and release gates

Mobile navigation

Jump to section

Open

This page is the shortest curated map of the repository.

patentchecker has a large workflow surface. That is useful for shipping, but it also means the first screen can make stable product lanes, experimental workbench flows, and internal operating machinery look equally important.

Use this page to answer two questions quickly:

Which surfaces are the primary product and contributor paths?
Where is the source of truth for compatibility and validation?

The detailed compatibility contract lives in SUPPORTED_SURFACES.md. The detailed validation contract lives in docs/testing-matrix.md. The concrete end-to-end lane narratives live in docs/runtime-flows.md. The maintainer ownership and blast-radius note lives in docs/ownership-hotspots.md. The Node/Python boundary note lives in docs/node-python-boundary.md. The repository boundary note lives in docs/repo-boundaries.md. The workflow-family extraction policy lives in docs/workflow-family-policy.md. The live-data scope note lives in docs/external-data-strategy.md. The shared terminology reference lives in docs/glossary.md.

Machine-readable policy: config/supported_surfaces.policy.v0.1.json

Contributor fast path

Use this table when you need a first-pass validation decision before reading the longer policy docs.

If you changed	Start here	Minimum commands
Fresh clone, contributor-machine sanity check, or "what should I run first?"	README.md quickstart plus the repo-local bootstrap	`npm run contributor:smoke`
TS/JS runtime, CLI, or business logic	`src/`, packaged commands, or user-facing JS/TS workflows	`npm test`
Buyer verification, packet validation, or public release contract wiring	docs/public-release-surface.md, docs/demo-offline-packet-quickstart.md, and docs/testing-matrix.md	`npm run miec:verify`; add `npm run ci:public-release-surface-invariants`; add `npm run integrity:all -- --quiet` for buyer-visible or published-artifact changes
Watchlist authoring, runner behavior, adapter integration, or run verification	docs/runtime-flows.md, docs/watchlist-authoring.md, and docs/testing-matrix.md	`npm run test:watchlist`; add `npm run demo:watchlist` and `npm run verify:run -- <run_dir>` when you need a concrete run
Patent valuation normalization, scoring, or signed bundle generation	docs/runtime-flows.md, docs/METHOD.md, docs/EVALUATION.md, and docs/testing-matrix.md	`npm run test:valuation`; add `npm run validate:examples`; add `npm run evidence-kit:check-golden` when canonicalization, signing, or bundle serialization changed
MCP server tools, resources, manifest, or stdio startup wiring	docs/mcp-server.md, `src/mcp/`, and the packaged `patentchecker-mcp` surface	`npm run test:mcp`; add `npm run ci:supported-surfaces-invariants` when the documented MCP contract changes
Self-serve onboarding bridge, preflight, first-run, or receipt verification	docs/self-serve-client-onboarding.md, docs/self-hosting.md, and docs/testing-matrix.md	`npm run test:self-serve-bridge`; add `npm run ci:supported-surfaces-invariants` when the documented bridge contract changes
Platform-owned self-serve packaging, billing, queueing, ops-request, evaluation, or upgrade lifecycle flows	docs/workflow-family-policy.md, docs/self-hosting.md, docs/self-serve-client-onboarding.md, and docs/testing-matrix.md	`npm run test:platform-self-serve`; use `npm run test:platform-self-serve:ops-request` here for wrapper-handoff changes and the same lane in `../patentchecker-platform` for functional queue behavior; use `npm run test:platform-self-serve:evaluation:delivery` and `npm run test:platform-self-serve:upgrade:delivery` here for delegated delivery wrappers and the matching lanes in `../patentchecker-platform` for functional delivery monitoring behavior; use `npm run test:platform-self-serve:evaluation` here for delegated evaluation delivery/follow-up wrappers plus the remaining local outcome/activation/issuance slice, and run the same lane in `../patentchecker-platform` when evaluation delivery or follow-up behavior itself changed; use `npm run test:platform-self-serve:upgrade` here for delegated upgrade transition wrappers plus the remaining local ship/apply/return slice, and run the same lane in `../patentchecker-platform` when upgrade transition behavior itself changed; add `npm run ci:supported-surfaces-invariants` when the documented family contract changes
Buyer/release assets, mirror docs, or release workflow wiring	docs/public-release-surface.md, release workflows, and buyer-facing release docs	`npm run miec:verify`; add `npm run ci:public-release-surface-invariants`; add `npm run integrity:all -- --quiet` for full buyer-path confidence
Support policy, contributor docs, or validation guardrail wiring	this page, SUPPORTED_SURFACES.md, and docs/testing-matrix.md	`npm run ci:supported-surfaces-invariants`
Python-backed workflows or documented repo-run Python entrypoints	docs/python-workflows.md, docs/node-python-boundary.md, docs/evidence_types.md, and docs/sequence_listings.md	`npm run test:python`; `npm run ci:python-surface-invariants`
Pre-release or buyer-visible changes that cross multiple lanes	the affected lane docs plus docs/testing-matrix.md	`npm run sellable:v1`; `npm run integrity:all -- --quiet`

Canonical npm entrypoints

Treat these as the default npm commands for repo orientation, generic automation, and first-pass contributor decisions.

These are the policy-backed repo entrypoints under workflow_surface.primary_npm_entrypoints in config/supported_surfaces.policy.v0.1.json.

Commands starting with a prefix from workflow_surface.non_default_prefixes must stay out of this default list. If a family workflow earns promotion, promote the lane and policy deliberately instead of adding demo:*, self-serve:*, or another family command to the default inventory.

Bootstrap and preflight

build via npm run build
repo:doctor via npm run repo:doctor -- --json --strict-local-runtime
contributor:smoke via npm run contributor:smoke
ecosystem:doctor via npm run ecosystem:doctor -- --json

Default regression and artifact validation

test via npm test
test:watchlist via npm run test:watchlist
test:valuation via npm run test:valuation
test:python via npm run test:python
miec:verify via npm run miec:verify
validate:examples via npm run validate:examples
evidence-kit:check-golden via npm run evidence-kit:check-golden

Product runtime and verification

verify:run via npm run verify:run -- <run_dir>
watchlist:compile via npm run watchlist:compile
watchlist:lint via npm run watchlist:lint
watchlist:run via npm run watchlist:run
watchlist:daemon via npm run watchlist:daemon

Policy and release gates

ci:supported-surfaces-invariants via npm run ci:supported-surfaces-invariants
ci:runtime-metadata-invariants via npm run ci:runtime-metadata-invariants
ci:python-surface-invariants via npm run ci:python-surface-invariants
ci:public-release-surface-invariants via npm run ci:public-release-surface-invariants
ci:workflow-security-invariants via npm run ci:workflow-security-invariants
sellable:v1 via npm run sellable:v1
integrity:all via npm run integrity:all -- --quiet
release:mirror:smoke via npm run release:mirror:smoke -- --quiet

Everything else in package.json is lane-specific, experimental, or maintenance-oriented. It may still be documented and supported, but it is not the default repo entrypoint set.

That includes mcp:server: it is a supported surface, but it is intentionally a lane-specific integration entrypoint rather than a default first command.

Non-default workflow families

The policy also marks large non-default workflow families so contributors do not mistake package breadth for one flat support level.

The family-by-family stance, planned home, extraction phase, and max_script_count caps live under workflow_surface.family_policies and docs/workflow-family-policy.md.

demo:
self-serve:
platform:self-serve:
experiment:
exposure-bundle:
intellia-risk-bundle:
outreach:
sales:
prime:

Those families can contain useful and sometimes supported workflows. They are simply not the first commands to reach for when orienting to the repo or building generic automation against it.

For self-serve:, the maintained repo-owned bridge is the smaller allowlist recorded under workflow_surface.family_policies[].bridge_scripts: self-serve:provision, self-serve:doctor, self-serve:first-run, self-serve:license-status, self-serve:verify-receipt, and self-serve:verify-rotation-receipt. The matching focused maintainer entrypoint now lives under workflow_surface.family_policies[].focused_validation_scripts as test:self-serve-bridge. Readiness bundles, starter packaging, rotation, billing, delivery, queue, and follow-up flows now live under platform:self-serve:* while they still live in this repo, and their focused validation entrypoints are likewise recorded under workflow_surface.family_policies[].focused_validation_scripts rather than left as raw test-file lists in prose. The platform:self-serve:ops-request:* slice is now delegated to patentchecker-platform, so this repo's focused ops-request lane covers wrapper handoff while the platform repo owns the functional queue behavior. Within platform:self-serve:evaluation:*, the delegated subset now includes both the delivery-monitoring trio and the delivery/follow-up operator-ledger trio, so test:platform-self-serve:evaluation:delivery covers the monitoring wrappers here while test:platform-self-serve:evaluation covers the delegated delivery/follow-up wrappers plus the remaining local outcome/activation/issuance slice; run the same evaluation lane in patentchecker-platform when functional delivery or follow-up behavior changed. Within platform:self-serve:upgrade:*, the delegated subset now includes both the delivery-monitoring trio and the operator-ledger transition quartet, so test:platform-self-serve:upgrade:delivery covers the delivery wrappers here while test:platform-self-serve:upgrade covers the delegated transition wrappers plus the remaining local ship/apply/return slice; run the same upgrade lane in patentchecker-platform when functional transition behavior changed. Those delegated subfamily boundaries are now explicitly marked in workflow_surface.family_policies[].subfamily_path_policies with wrapper_only or delegated_scripts, plus delegated_to_repo, delegate_helper_path, and delegated_script_path_prefix, so the machine-readable policy distinguishes local compatibility boundaries from local lifecycle implementations. The internal outreach:, sales:, and prime: families use the same pattern with test:internal-outreach, test:internal-sales, and test:internal-prime, and the experimental collateral/bundle families now do the same with test:demo, test:exposure-bundle, and test:intellia-risk-bundle, with entrypoints grouped under scripts/demo/, scripts/exposure_bundle/, and scripts/intellia_risk_bundle/.

Core lanes

These are the lanes contributors and operators should treat as the canonical repo surface.

1. Buyer and offline verification surface

Audience:

evaluators
procurement reviewers
counsel
release consumers

Primary entrypoints:

docs/runtime-flows.md
docs/evaluation-quickstart.md
docs/demo-offline-packet-quickstart.md
docs/verify-before-you-buy.md
docs/public-release-surface.md
README.md release and verification sections
npm run verify:run -- <run_dir>

Use this lane when the question is: "Can a third party verify the output locally without trusting a hosted service?"

Minimum validation when changing it:

npm run miec:verify
npm run ci:public-release-surface-invariants
npm run integrity:all -- --quiet when the change is buyer-visible or published as a release artifact

2. Watchlist and monitoring surface

Audience:

operators
product users running ongoing monitoring

Primary entrypoints:

npm run test:watchlist
docs/runtime-flows.md
npm run watchlist:compile
npm run watchlist:lint
npm run watchlist:run
npm run watchlist:daemon
docs/watchlist-authoring.md

Use this lane when the question is: "How do we author, run, and verify a monitoring program?"

Live upstream search belongs to this lane, but it belongs behind the adapter contract rather than as repo-local search code. See docs/external-data-strategy.md.

Minimum validation when changing it:

npm run test:watchlist
npm run demo:watchlist or npm run verify:run -- <run_dir> when the change needs a concrete run
docs/testing-matrix.md for higher-order checks

3. MCP automation surface

Audience:

MCP client authors
automation and agent integrations
maintainers evolving the documented server contract

Primary entrypoints:

npm run test:mcp
docs/mcp-server.md
npm run mcp:server
patentchecker-mcp --repo-root <path>
node dist/src/mcp/patentchecker_mcp_server.js --repo-root <path> --print-manifest

Use this lane when the question is: "How does an MCP client call PatentChecker's supported tools and resources without reverse-engineering repo-local CLI wiring?"

This lane is first-party and supported, but it stays out of the default npm shortlist because it is an integration transport rather than a first-pass contributor command.

Minimum validation when changing it:

npm run test:mcp
add npm run ci:supported-surfaces-invariants when changing docs/mcp-server.md, the packaged MCP binary contract, or the maintained support-tier docs

4. Patent valuation and evidence bundle surface

Audience:

R&D users
analysts
teams producing deterministic evidence artifacts

Primary entrypoints:

Use this lane when the question is: "How do we produce deterministic scored output, bundles, and replayable evidence?"

This lane currently starts from structured source records or normalized inputs, not a live upstream valuation adapter. See docs/external-data-strategy.md.

Minimum validation when changing it:

npm run test:valuation
npm run validate:examples
npm run evidence-kit:check-golden when touching canonicalization, signing, or bundle serialization

5. Python-backed verification and provenance helpers

Audience:

contributors touching Python-backed evidence or verification paths
operators using documented repo-run Python entrypoints

Primary entrypoints:

docs/python-workflows.md
docs/node-python-boundary.md
docs/evidence_types.md
docs/sequence_listings.md
npm run test:python
npm run ci:python-surface-invariants

Use this lane when the question is: "Which Python-backed workflows are supported by the repo contract, how do they relate to the Node-first lanes, and how are they validated?"

Minimum validation when changing it:

npm run test:python
npm run ci:python-surface-invariants

6. Contributor validation and release guardrails

Audience:

maintainers
release operators
reviewers deciding what must pass for a change

Primary entrypoints:

docs/testing-matrix.md
docs/ci-invariants.md
docs/public-release-surface.md
SUPPORTED_SURFACES.md
config/supported_surfaces.policy.v0.1.json
config/public_release_surface.policy.v0.1.json
npm test
npm run ci:supported-surfaces-invariants
npm run ci:public-release-surface-invariants
npm run sellable:v1
npm run integrity:all -- --quiet

Use this lane when the question is: "What is the supported validation contract for this change?"

Support-level summary

Use the longer document for policy details. This is the practical summary.

Stable: packaged CLI binaries, versioned contracts and schemas, frozen adapter contract, and published verification paths
Supported but evolving: documented workflow wrappers, the first-party MCP server, and documented distribution modes
Experimental: experiments, scenario pipelines, and collateral-generation flows without a separate versioned contract
Internal: direct src/ imports, dist/ layout assumptions, helper scripts, generated wiki pages, and validation harness internals

How to use this map

Start here when the repo feels too wide.
Move to docs/repo-focus-plan.md when the question is how to reduce surface area without weakening the product contract.
Move to docs/repo-boundaries.md when the question is what belongs in this repo versus sibling repos or internal operating machinery.
Move to docs/workflow-family-policy.md when the question is which script families are intentionally non-default, which ones stay secondary here, and which ones should move elsewhere.
Move to docs/external-data-strategy.md when the question is whether a lane starts from live upstream data or from captured structured inputs.
Move to SUPPORTED_SURFACES.md when you need the compatibility promise.
Move to docs/testing-matrix.md when you need the validation contract.
Move to docs/glossary.md when repo terms or release vocabulary are unfamiliar.
Move to the lane-specific docs above when you need exact commands or user-facing workflow details.
Treat docs/wiki/ as orientation only; use the docs linked above for compatibility and release decisions.