Lab Mode and Scope Bypass

How WitnessOps documents the exception path for lab execution, scope bypass, and non-production testing.

Normal governed execution expects scope enforcement to pass before a step runs. Lab mode exists for the cases where that assumption is intentionally suspended for internal testing, demos, or isolated validation.

This page defines the exception path.

What lab mode is

Lab mode is a documented deviation from the normal governed path.

Use it only when all of these are true:

the objective is internal validation, training, testing, or sandboxed reproduction
the targets are non-production or explicitly authorized for bypass testing
the bypass itself is part of the approved exercise
the resulting record will not be presented as normal governed production evidence

Lab mode is not a convenience flag for “move faster.”

What scope bypass means

The command surface exposes two relevant flags:

--lab marks the run as a lab execution
--no-scope bypasses scope enforcement

Treat --no-scope as a lab-only escape hatch. If you cannot explain why scope enforcement must be bypassed, do not use it.

See Commands for the command reference.

Required controls before use

Before running in lab mode or with scope bypass, define:

the reason governed scope enforcement is insufficient for this run
the exact target boundary for the lab activity
the named approver responsible for accepting the extra risk
the environment classification: lab, sandbox, demo, or isolated test tenant
the stop condition if the activity touches unintended systems or data

If those controls are not written down, the run should not proceed.

What the evidence record must show

A lab or bypassed run should be unambiguous in the evidence chain.

At minimum, the record should show:

that the run was marked as lab activity
whether scope enforcement was bypassed
who approved the exception
why the exception was needed
which target boundary was still intended
whether any sensitive data was collected during the run

In the current receipt model, scope_validated: false means the run did not follow normal scope enforcement. That is not a minor detail. It is a different trust posture.

What lab mode must never be used for

Do not use lab mode or scope bypass for:

production customer environments without explicit written exception approval
retroactively justifying out-of-scope work
mixing sandbox validation with standard governed campaign evidence
collecting more sensitive data than the lab objective requires
work that would be unsafe even if fully approved

If the real goal is production testing, expand scope properly instead of bypassing it.

Failure states

Treat these as hard failures:

the run used --no-scope without a named approving principal
the evidence does not make lab status obvious
a production target was included in what was claimed to be a lab run
the run produced sensitive artifacts without a handling plan
the bypassed run is later cited as if it had normal scope enforcement

The right response is not to massage the record. It is to preserve the exception path honestly.

Trust boundary

Lab mode does not weaken the need for receipts. It weakens what the receipt can prove about authorization.

A bypassed receipt can still prove:

the run happened
the artifacts are linked to the run
the recorded principals and timestamps are intact

It cannot prove:

that the run respected normal scope controls
that the exception was appropriate
that the target boundary was externally authorized unless that approval was recorded