Document Type: Canon
Status: Canon
Version: v0.2
Authority: SIT Brain
Applies To: SITengine v0.1 manual runs
Parent: SIT Brain Canon
Last Reviewed: 2026-03-15
Purpose
This schema defines the minimum required structure for SIT logs.
Logs are evidence.
If logs are inconsistent, SIT is invalid.
Scope
This canon applies to:
• SITengine v0.1 manual-run logging
• SIT log storage location rules
• single-run log record structure
• required SIT log fields
• optional step-results structure
• immutability and retention discipline for SIT logs
This document governs the minimum schema required for valid SIT logging.
It does not govern:
• SITengine business logic
• automated monitoring loops
• dashboard design
• experiment validation outside SITengine runs
• general MWMS task logging
• multi-version SIT log expansion beyond v0.1
Those remain governed by SIT Brain Canon, SIT Engine – Minimal Design Specification, SIT Build Handoff Pack, and later SIT versions if approved.
Definition / Rules
Logging Location Rule (v0.1)
SIT logs must be stored in exactly one place:
• Primary Store: Supabase (preferred)
• Fallback Store: WordPress database, only if Supabase unavailable
SITengine must never write logs to multiple locations for the same run.
One Run = One Log Record
Every SITengine run must create exactly one immutable log record.
No partial logs.
No multi-row logs per single run.
Required Fields (Minimum)
Each log record must include:
• run_id (unique)
• timestamp (UTC)
• engine_version (for example v0.1)
• overall_result (PASS or FAIL)
• failed_step (nullable; required if FAIL)
• failure_reason (nullable; required if FAIL; one primary reason only)
• task_id (nullable; required if a test task was created)
• notes (optional)
Step Results (Optional but Recommended)
If stored, step results must be a single JSON object with these keys only in v0.1:
• health_supabase (PASS / FAIL)
• health_tasks_read (PASS / FAIL)
• health_tasks_write (PASS / FAIL)
• smoke_task_e2e (PASS / FAIL)
No extra keys in v0.1.
Immutability Rule
Once written, SIT log records must not be edited.
If a correction is required:
• write a new log record
• reference the prior run_id in notes
Validity Rule
A SIT run is considered invalid if:
• no log record exists, or
• required fields are missing, or
• overall_result is not PASS / FAIL
Invalid runs are treated as FAIL for operational purposes.
Retention Rule (v0.1)
Minimum retention:
• keep last 100 SIT runs, or more
• do not delete logs during active development
Final Rule
SIT without logs is opinion.
SIT with logs is governance.
Drift Protection
The system must prevent:
• one SIT run creating multiple log rows
• SIT logs being written to multiple stores for the same run
• mutation of records after insert
• non-standard result values replacing PASS / FAIL
• v0.1 step-results objects expanding with uncontrolled keys
• missing logs being treated as successful runs
SIT logging must remain singular, immutable, and schema-bound.
Architectural Intent
SIT Log Schema exists to make SITengine evidence durable, reviewable, and enforceable.
Its role is to ensure that every manual SIT run leaves behind one structurally valid audit record so system integrity is judged by traceable evidence rather than memory or 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 purpose, logging-location rule, one-run-one-log rule, required fields, optional step-results structure, immutability rule, validity rule, retention rule, and final-rule logic. Added Document Type, Parent, Purpose / Scope / Definition / Rules structure, Drift Protection, Architectural Intent, and updated the review date.
Version: v0.1
Date: 2026-02-13
Author: SIT Brain
Change: Initial creation of SIT Log Schema defining the minimum required structure for SITengine v0.1 manual-run logs.
END – SIT LOG SCHEMA v0.2