Document Type: Specification
Status: Draft (until pasted + locked)
Version: v0.2
Authority: SIT Brain
Applies To: System integrity verification (manual-run)
Parent: SIT Brain Canon
Goal: A single manual “Run SIT” action that proves the system pipeline is alive and logs the result.
Last Reviewed: 2026-03-15
Purpose
This document defines the minimum design specification for SITengine v0.1.
Its purpose is to establish a tightly bounded, manual integrity runner that proves whether the MWMS task pipeline is alive end-to-end at the moment of execution.
SITengine v0.1 must remain minimal, mechanical, and evidence-based.
Scope
This specification applies to:
• manual SITengine execution
• health-check and smoke-test design
• PASS / FAIL evidence rules
• minimal SIT UI requirements
• immutable run logging
• timeout and polling defaults for v0.1
This document governs the design of the first manual SITengine.
It does not govern:
• automatic enforcement
• output blocking logic
• continuous monitoring
• compliance interpretation
• optimisation logic
• issue repair workflows
Those remain outside v0.1 scope unless separately approved.
Definition / Rules
What SITengine v0.1 Is
A manual smoke-test harness.
It does not block work.
It does not auto-enforce.
It does not gate output.
It only answers:
“Can MWMS create, process, and complete a task end-to-end right now?”
Allowed Inputs
SITengine uses only mechanical system facts:
• Supabase connection availability
• task record lifecycle states, for example pending → complete / failed
• existence of task execution traces, events, or runs if available
• timestamped logs
No strategy.
No recommendations.
SITengine v0.1 Output (Single Truth Result)
Every run produces:
A. Human Result
• Overall: PASS / FAIL
• Failed step name, if any
• Primary failure reason, single sentence
• references: task_id, run_id, event ids if available
B. Immutable Log Record
Written into a SIT log store, table or JSON log, containing:
• timestamp
• run_id
• overall_result
• step_results, pass / fail per step
• failure_reason, if fail
• task_id created, if applicable
• system snapshot, site or plugin version if available
SITengine v0.1 Manual Run Flow (Conceptual)
When admin clicks Run SIT:
Step A – Health Checks (No Task Creation Yet)
• Supabase reachable
• tasks table writable, can write a log row or do a harmless insert test
• OpenAI reachable, optional in v0.1 if OpenAI calls are only made through executor
If any fail → FAIL immediately.
Step B – End-to-End Task Smoke Test
SITengine creates a SIT test task using the same task pipeline that Affiliate / HeadOffice uses.
Design rule:
The test task must use the same initial status the executor watches.
Observed assumption:
pending is the initial queue state unless the live system defines otherwise.
Lifecycle expectation:
pending → optional: processing / running → complete OR failed
SITengine watches the task until:
• it becomes complete → PASS for this step
• it becomes failed → FAIL with reason
• it remains pending too long → FAIL: timeout
Step C – Log + Show Result
SITengine writes a single log record and shows:
• PASS / FAIL
• last 10 run history
Minimum Data Contract (v0.1)
This is the design contract, not a build instruction.
The tasks table must support:
• id
• status, must include at least: pending, complete, failed
• payload_json (jsonb)
• employee_id, optional for SIT test but preferred
• created_at
SIT Test Payload (Design)
payload_json.kind must be unique and machine-detectable:
{
"kind": "sit_test_v0_1",
"notes": "SITengine smoke test",
"expected_behavior": "executor should process and mark complete"
}
Success Evidence (Design)
A SIT run counts as a true PASS if:
• a task exists with kind = sit_test_v0_1
• its status transitions away from pending
• it ends in complete
• a completion footprint exists, either in the task row or in task_events / task_runs if those tables are used
Pass / Fail Rules (Hard)
PASS only if:
• health checks pass
• task smoke test completes successfully within the timeout window
• log record is written
FAIL if:
• any health check fails
• task ends as failed
• task stays pending beyond timeout
• logging fails, because audit trail is mandatory
Timeouts (v0.1 Defaults)
• health checks: immediate
• task lifecycle timeout: 60 seconds
• poll interval: 2 seconds conceptually
These are design defaults and may be tuned later.
UI Requirements (Minimal)
A WordPress Admin page:
SIT → Run SIT
Contains:
• “Run SITengine v0.1” button
• “Last Result” card, PASS / FAIL + reason
• “History” table, last 10 runs
No graphs.
No dashboards in v0.1.
Non-Goals (Explicitly Out of Scope)
SITengine v0.1 does NOT:
• auto-block outputs
• run continuously
• evaluate copy or marketing tone
• perform compliance interpretation
• fix issues
• optimise anything
It only reports evidence.
Drift Protection
The system must prevent:
• SITengine v0.1 expanding into automation or governance logic
• PASS being shown when the immutable log is missing
• fake health status without end-to-end task proof
• smoke-test tasks using a different path than the real executor pipeline
• output verbosity expanding into analysis or advisory behaviour
• manual integrity checks being mistaken for operational approval
SITengine v0.1 must remain narrow, mechanical, and auditable.
Architectural Intent
SIT Engine – Minimal Design Specification exists to ensure the first SIT engine is small enough to trust.
Its role is to verify pipeline aliveness through one manual, evidence-based run that checks system health, proves task flow, and writes an immutable audit record without drifting into automation, optimisation, or operational control.
Final Rule
If the pipeline looks alive but cannot prove completion and log the run immutably, the result is FAIL.
Evidence outranks appearance.
Change Log
Version: v0.2
Date: 2026-03-15
Author: MWMS HeadOffice
Change: Rebuilt page to align with the locked MWMS document standard for this cleanup pass. Preserved the original minimal SITengine concept, allowed inputs, output requirements, manual run flow, minimum data contract, SIT test payload, success evidence rules, pass / fail rules, timeout defaults, minimal UI requirements, and explicit non-goals. Added Document Type, Parent, Last Reviewed, Purpose / Scope / Definition / Rules structure, Drift Protection, Architectural Intent, Final Rule, and standardised formatting.
Version: v0.1
Date: Prior entry preserved
Author: MWMS HeadOffice
Change: Initial minimal design specification for a manual SIT smoke-test runner.
END – SIT ENGINE – MINIMAL DESIGN SPECIFICATION v0.2