# Enter System Context Only With A Stated Reason

Keeps the machine-caller bypass narrow, because entering it skips the tenant check entirely.

Follow these project instructions.
# Enter System Context Only With A Stated Reason

Keeps the machine-caller bypass narrow, because entering it skips the tenant check entirely.

Version: `1.0.0`

There is a system context for work that has no user behind it. While it is active, the operation executor returns before the tenant demand and before the authorizer, so the call proceeds with no tenant check and no permission check at all.

That makes it the right tool for a startup migration or a provider webhook, and a dangerous one everywhere else. Enter it around the narrowest possible piece of work, and leave it as soon as that work is done - never for the length of a request, and never around a call that will later handle user input.

Entering requires a reason. Write one that names the job, so an audit entry can be read later without guessing why the checks were skipped.

Two limits are worth knowing. The bypass exists only in the operation executor, so a base CRUD write still demands a tenant and will throw for a machine caller. And when a tenant check fails for a job, reach for the system context only after confirming the job genuinely has no tenant - most of the time the real fix is to supply the tenant the work belongs to.

#### Constraints
- Do not hold system context open for the length of a request.
- Never enter it with a vague reason - name the job.
- Never enter system context around a call that handles user input.

#### Verification
- Each use was checked to be work that genuinely has no tenant
- Every entry into system context names the job it covers
- The scope covers one unit of work and is left immediately after