Evidence and policy

Tapid's central design question is not "is this package safe?" It is: what exactly is being used, what is known about it, and which rule permits or stops this operation?

Start with an exact target

A request such as acme-widget@^2.4 is a constraint, not an artifact identity. A useful decision starts with a selected version, registry identity, and artifact digest. Read Package identity for the model that binds those values together.

Evidence describes what was found

Evidence may include publisher context, release changes, available provenance, package metadata, artifact inspection, and observations from an execution. Capability signals can include lifecycle scripts, native code, network access, filesystem access, and other operations that may affect a project or machine.

Each evidence source has limits. Metadata is not runtime observation. Static inspection is not proof of runtime safety. A planned provenance record is not an attestation that exists today. The interface should show both the evidence and its source.

Policy explains what happens next

A future policy layer can consume evidence for one operation and produce an outcome: allow, warning, prompt, or denial. The same evidence may lead to different outcomes for local development, CI, or unattended automation.

Tapid should not compress uncertainty into an unexplained safety score. A useful result names the evidence, the rule, the decision, and the limitation.

What is implemented today

The current client validates lockfile replay, verifies the supported store inputs, materializes managed node_modules, and suppresses dependency lifecycle scripts during install. It does not yet provide an evidence service, publisher provenance verification, a policy engine, a sandbox, or runtime capability enforcement.

The local fixture checks this narrow boundary:

Replayed lockfile: 0 package(s)
Verified: node_modules created; dependency lifecycle marker absent.

That output demonstrates a test path. It is not a security verdict about arbitrary packages.

Registry and publishing boundary

The current client supports a local JSON registry fixture for tests and air-gapped development. It does not provide private-registry authentication, publishing, a discovery service, or a complete public npm compatibility surface.

Future registry routing should make the source explicit. A private scope should not fall through to a public registry because a configuration entry is missing. Credentials should stay within the registry boundary that needs them and should never be silently sent to another origin.

A future publishing flow should record publisher identity, provenance where available, and release changes that affect an artifact. Namespace governance, revocation, and independent verification remain design work.

Agent and execution boundary

The current client does not provide an agent runner or command execution service. tapid run <script> is an explicit root-script command, and root scripts may execute arbitrary project code through the platform shell. It is not a sandbox or a security boundary.

A future integration may provide an agent with exact package identity, artifact digest, registry and publisher context, release changes, capability signals, policy outcome, and evidence limitations. Fail-closed unattended behavior is a design target, not a current guarantee.

Continue the decision path

Read Getting started for the supported project path and Commands for the current CLI surface. Read the implementation threat model and security policy for repository-level boundaries.