FaultTrellis
PRODUCT IN DEVELOPMENT

OPERATING PRINCIPLES

Clear limits.
Honest records.

FaultTrellis is being built to support backend reliability work without treating urgency as permission to act.

THREE COMMITMENTS

Keep the boundary visible.

01

Rules define the boundary

Any future operational action must fit a defined scope and an explicit approval rule. If the scope or evidence is uncertain, or the operation is out of scope, the intended behavior is to stop for review.

02

Reports separate the facts

Incident reporting should distinguish what was proposed, what was approved, and what actually ran. Approval is not execution; when nothing ran, the record should say so.

03

People resolve uncertain calls

When context calls for judgment or a safe next step is unclear, the planned system pauses, leaves the decision to a person, and does not proceed on a guess.

AN ACTION IS A FACT TO VERIFY

Proposed, approved, and executed are different states.

An incident record should not turn a suggestion or permission into a claim that work happened.

  1. 01

    Proposed

    Suggested for consideration. It has not run.

  2. 02

    Approved

    Authorized within scope. Approval alone does not mean it ran.

  3. 03

    Executed

    Recorded only when the action actually ran and that outcome is known.