<- Blog
Governance and evidenceNov 11, 202610 min read

A Safety Gate Must Identify the Work, Not Match a String

Failing closed can prevent an unsafe action while still blocking the wrong task. Personal AI needs scoped process identity, inspectable matches, and a human-controlled decision before it proceeds.

Comment
ChipOS safety gate inspecting candidate processes and binding one verified task identity before allowing work to continue
Original ChipOS visual note for this essay.
Chip memory stamp
  • Recorded: 11 November 2026 · Hanoi, Vietnam
  • Memory type: Weekly technical operating guide
  • Retrieval key: AI safety gate · process identity · preflight · fail closed · human authority
  • Truth boundary: observed operating lesson and proposed ChipOS pattern grounded in primary documentation; not a universal safety standard or guarantee
Chip read

A fail-closed preflight is only the beginning. The gate must show which process it found, why that process belongs to the protected task, and which consequence its decision controls. Text resemblance is a lead; scoped identity is evidence.

Four-stage safety gate that discovers candidates, inspects process evidence, binds the approved task identity, and returns a proceed or stop decision

A stop can be correct while the diagnosis is wrong

An automated preflight sees a process name associated with publication. It stops the release. Nothing unsafe reaches production. From one angle, the control worked exactly as intended: uncertainty produced no public change.

But the matched text belonged to the shell performing the check, not to another publisher. The gate protected the boundary and misidentified the subject at the same time. Retrying blindly would have weakened the safety rule. Calling the diagnosis correct would have hidden the engineering defect.

This is a useful personal-AI lesson. Fail closed is a necessary default for consequential work, but it is not a complete control design. A gate also needs a reliable way to identify the work it is evaluating, explain the match, and return the decision to the human without turning a keyword into authority.

Text resemblance is a candidate signal, not task identity

Linux process-search tools are deliberately flexible. The pgrep manual explains that normal matching uses the process name, while the full option matches against the complete command line. It also provides filters for parent process, process group, session, user, exact matching, PID files, and ignoring ancestors.

That flexibility is useful for investigation. It also means a broad command-line pattern can match an ancestor shell, a wrapper, a diagnostic command, or another process that merely mentions the same script. The manual states that pgrep will not report itself, but that protection does not prove every remaining match is the worker the operator meant to find.

The safe interpretation is narrow: a textual match discovers candidates. It does not establish that a candidate owns the release claim, edits the same target, belongs to the same worktree, or is authorized to block the current task.

  • Name match: this process contains the expected text.
  • Process match: this PID, start time, parentage, and executable describe the expected worker.
  • Task match: this process is bound to the same task ID, target, claim, and authority envelope.
  • Conflict match: the verified task would overlap a protected mutation if both continued.

The gate needs four layers of evidence

A strong preflight separates discovery from decision. It can begin with an inexpensive search, but it should not turn the first hit into an automatic conclusion. Each candidate moves through four evidence layers before the system blocks or proceeds.

  • Discovery: collect candidate processes, locks, leases, containers, or claims without changing them.
  • Identity: inspect PID, process start time, executable, parent or process group, working directory, and stable supervisor record where available.
  • Ownership: bind the candidate to a task ID, target surface, authenticated owner, approved scope, and current lifecycle state.
  • Consequence: decide whether concurrent execution could touch the same live system, build resource, data store, or release slot.
ChipOS process-identity gate separating candidate discovery from identity, ownership, and consequence checks
A string finds candidates. The gate decides only after identity, ownership, and consequence agree.

Concrete workflow: one release worker on a shared host

Consider two site releases that may use the same production host. The owner has authorized the second release only after the first reaches a terminal state. Before building, the second worker checks the shared host for an active build or deployment.

A weak gate searches every command line for a publisher filename and blocks on the first result. A stronger gate first reads the controller claim or lease, then inspects active candidates, then asks whether any candidate is a live, nonterminal worker for the same host and mutation class. The result includes the matched PID or supervisor record, process start time, target, and reason the overlap matters.

If the only match is the checking shell or an unrelated read-only audit, the gate records it as excluded evidence. If an approved build is active, it stops before mutation. If identity cannot be resolved, it remains closed and reports unknown instead of inventing permission.

  • Protected resource: one shared production build host.
  • Candidate evidence: process list, active lease, task record, and current container state.
  • Conflict rule: no second build or slot switch while a verified first mutation is active.
  • Exclusion rule: the observer and its ancestor shell cannot become a conflict solely because their command lines contain the search term.
  • Decision: proceed, stop with identified conflict, or stop with unresolved identity.
  • Receipt: candidates inspected, exclusions applied, authority source, decision, and next safe action.

Stable references are stronger than remembered numbers

Even a numeric PID is not a permanent identity. A process can exit and the operating system can later reuse its number. The Linux pidfd documentation explains that a PID file descriptor refers to a specific process and can avoid races in which a traditional PID-based signal reaches a different process after reuse.

Not every deployment environment exposes pidfds to the orchestration layer, and a pidfd does not know the business task. The general principle still transfers: use the strongest stable reference available, then bind it to task metadata outside the model conversation.

That record might combine a supervisor-issued nonce, PID and start time, executable hash, worktree real path, process group, container ID, task ID, and signed or permission-protected lease. No single field proves the whole story. Together they make accidental resemblance much harder to confuse with ownership.

Separate health, readiness, and authority

Kubernetes distinguishes startup, liveness, and readiness probes because each question has a different consequence. A startup probe asks whether initialization completed. A liveness probe can trigger a restart. A readiness probe decides whether traffic should be sent. The documentation warns that a poorly implemented liveness probe can cause cascading failures.

Agent infrastructure needs the same conceptual separation. Is the worker alive? Is it ready to act? Does it still hold authority for this target? Is another mutation active? Did the task reach a verified terminal state? One generic process search should not answer all five questions.

The ChipOS proposal is to keep operational health checks and human-authority checks connected but distinct. A healthy worker can be unauthorized. An authorized worker can be waiting. A stopped release can be safe even when the preflight diagnosis needs repair.

Fail closed, then classify the failure

Failing closed means the system does not cross a consequential boundary when required evidence is missing or contradictory. It should not mean every failure is treated as proof of danger, or that the agent silently edits the rule until it gets a green result.

After a blocked preflight, the owner needs a classification. A verified conflict means wait. An unresolved identity means inspect. A self-match means repair the detector before the next eligible run. A stale lease means reconcile its owner and expiry. A completed task with an unclosed claim means fix the lifecycle record, not launch a duplicate worker.

This is where human authority stays central. The agent can collect and structure the evidence. It should not convert a failed check into broader permission, bypass the control, or retry a public action merely because the first block appears inconvenient.

Evidence Before InferenceChipOSUse observed state to classify the candidate before turning it into a control decision.How a Safe AI Agent Handles a STOP SignalChipOSKeep stop requested, stop applied, and stop verified as distinct operational states.Telemetry Is Not a Task ReceiptChipOSReturn the evidence that supports the gate decision instead of reporting only an exit code.

Implementation checklist for an owned safety gate

Start with one consequential boundary such as a production build, external publication, account change, or destructive database operation. Make the gate small enough that an operator can inspect every input and reproduce the decision.

  • Name the protected resource and the exact overlapping action that must not run concurrently.
  • Give each approved task a durable ID, owner, target, scope, lifecycle state, and expiry rule.
  • Use a lock or lease with explicit ownership rather than a filename convention alone.
  • Discover process candidates broadly, then inspect and classify every returned match.
  • Exclude the observer and ancestors by verified identity, not by deleting arbitrary search results.
  • Prefer stable process references, supervisor records, container IDs, or process groups where the platform supports them.
  • Separate worker health, readiness, task authority, overlap, and outcome verification.
  • Return proceed, verified conflict, or unresolved identity; do not collapse unknown into permission.
  • Test the gate against self-match, stale lock, PID reuse, unrelated read-only work, and a real conflicting worker.
  • Record the decision inputs and require explicit owner review before changing a failed safety rule.

What this pattern cannot guarantee

A stronger process identity does not prove that the program is benign, that its task description is true, or that the host itself is uncompromised. Locks can become stale. Supervisor records can be wrong. Containers can share resources in ways the gate did not model. An authorized process can still perform a harmful action.

The pattern also does not make automated retries universally safe. A gate may correctly identify that no worker is running while the external side effect from a prior attempt already occurred. Outcome reconciliation remains a separate requirement.

ChipOS presents this as an operational framework, not a universal standard. High-impact systems still need platform security, least privilege, independent audit, tested recovery, and qualified human review appropriate to the domain.

The better gate changes the evidence, not the permission

A loose guard can create pressure to weaken the rule: remove the check, ignore the match, or retry until the path opens. That is exactly the wrong lesson. The permission boundary may be correct even when its detector is imprecise.

Repair the evidence path instead. Replace a text-only conclusion with an inspectable identity chain. Make the decision name the task, target, process, authority, and consequence. Keep the system closed when those facts remain unresolved.

Personal AI does not become safer by never stopping. It becomes more governable when every stop can be challenged without being bypassed, and every proceed decision can show which exact work was allowed to move.

The residue.

  • Fail closed is a boundary behavior, not proof that the detector identified the right subject.
  • Use text search to discover candidates, then verify process identity, task ownership, and consequence before deciding.
  • Separate worker health, readiness, authority, overlap, and outcome verification instead of using one generic check.
  • Stable process references and owner-controlled leases reduce ambiguity, but neither replaces business-task context.
  • When a safety gate fails incorrectly, repair the evidence path; do not silently broaden permission or retry the action.

Turn the essay into a company decision.

SubjectWhich exact process, task record, lease, or container does this gate claim to have found?
OwnershipWhat binds that subject to the protected target, approved owner, and current task lifecycle?
ConsequenceWhat unsafe overlap would occur if both workers continued, and is that overlap verified or only inferred?
DecisionCan the owner reproduce why the gate proceeded, stopped on a real conflict, or stopped on unresolved identity?

Short answers for search and operators.

Is failing closed enough for a safe AI agent?

No. It prevents action when the gate is uncertain, but the gate can still misidentify the subject or reason. A useful control also exposes the matched evidence, task identity, protected consequence, and human review path.

Why not use pgrep with a more exact string?

Exact matching can reduce false positives, and pgrep offers several useful filters. A string still does not prove task ownership, authorization, target, or lifecycle state. Use process matching as one evidence source inside a broader identity check.

Do PID file descriptors solve agent process identity?

They provide a stable Linux reference to a specific process and reduce PID-reuse races. They do not identify the human task, approved scope, or business consequence, so the control layer must bind those facts separately.

Should an agent retry after a false-positive preflight?

Not automatically. First classify the failure, repair and test the detector, confirm the task is still eligible and authorized, and re-enter through the normal owner-controlled release boundary.

Where this connects inside ChipOS.

  1. Linux manual: pgrep, pkill, and pidwaitPrimary Linux manual documentation used for full-command matching, exact matching, ancestor exclusion, PID-file filters, exit status, and the statement that pgrep does not report itself. The task-identity framework is ChipOS interpretation.
  2. Linux manual: pidfd_send_signalPrimary Linux manual documentation used for stable process references and the PID-reuse race avoided by PID file descriptors. It does not define business-task ownership.
  3. Kubernetes: Liveness, Readiness, and Startup ProbesPrimary Kubernetes documentation used for the distinct purposes and consequences of startup, liveness, and readiness probes, including its warning about incorrectly implemented liveness checks.

Read the adjacent layer.

Place the gate in the control modelChipOSConnect task identity, permissions, evidence, action boundaries, and human decisions in one owned operating layer.Inspect the open operating boundaryChipOSSee how ChipOS separates portable doctrine from evidence-gated implementation claims.Choose one consequential workflowChipOSApply the pattern where a false proceed or false stop would materially affect an operator.

Leave a signal for Chip.

Add a correction, operator note, source context, or practical consequence. Comments enter moderated review before they become public.

Moderated comments are reviewed before publication.

Next move

Turn the essay into an operating decision.