# Evidence and policy

Source: https://tapid.dev/docs/concepts/evidence-and-policy

How facts, decisions, and future trust controls relate.

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](https://tapid.dev/docs-markdown/concepts/package-identity/content.md) 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 denies dependency lifecycle scripts by default, with exact approvals for supported online Linux execution. It does not yet provide an evidence service, publisher provenance verification, a package-evidence policy engine or complete runtime capability analysis. Published v0.0.13 also has experimental policy-controlled script execution with platform-specific limits. This execution policy is separate from the future package-evidence policy engine.

The registry-backed consumer path demonstrates this boundary:

```text
Installed 1 package(s)
Replayed lockfile: 1 package(s)
```

That output demonstrates installation and deterministic replay. It is not a security verdict about the installed package.

## Registry and publishing boundary

The current client supports npm registry metadata and artifacts for a documented compatibility subset, plus local fixtures for deterministic testing. Published v0.0.13 includes scoped private npm routing and explicit credentials as a development feature. It does not provide package publishing, hosted package-evidence discovery or complete npm compatibility. Read [Private registries](https://tapid.dev/docs-markdown/private-registries/content.md).

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>` launches an explicit Node.js root script under its configured execution policy. Published v0.0.13 requires `tapid.toml` and includes experimental platform-specific Restricted execution. Unsupported containment fails before launch; Restricted does not guarantee complete descendant cleanup. Read [tapid run](https://tapid.dev/docs-markdown/commands/run/content.md) for the platform and policy limits.

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](https://tapid.dev/docs-markdown/getting-started/content.md) for the supported project path and [Commands](https://tapid.dev/docs-markdown/commands/content.md) for the current CLI surface. Read the [implementation threat model](https://github.com/LimeTip/tapid/blob/main/docs/threat-model.md) and [security policy](https://github.com/LimeTip/tapid/blob/main/SECURITY.md) for repository-level boundaries.