Testing Example

LMU/COICP Example

Testing Example

Verify the integrated LMU/COICP baseline that will become RC-001: incident intake, evidence events, access checks, status transitions, emergency-boundary behavior, AI disablement, regression stability, and release-blocking defects.

ES-109 Testing Package LMU RC-001

Example AreaLMU/COICP

Current PageTesting Example

FocusLMU/COICP testing package

UseRead completed ES-109 artifacts

Repository Areadocs/examples/lmu-coicp/testing/

← Back Integration Readiness Summary

Current Testing Example

Next → Test Strategy

Purpose

This section contains the completed ES-109 — Testing and Verification example for the LMU Campus Operations and Incident Coordination Platform.

This is the testing package for the integrated baseline that becomes LMU-COICP-RC-001. It verifies whether the baseline is ready to enter ES-110 Release Readiness as an internal engineering review candidate only.

Testing does not approve release. Testing creates evidence, exposes defects, and makes release risk visible.

Testing context

Field	Value
Integrated baseline under test	LMU-COICP-INT-001
Candidate produced by testing	LMU-COICP-RC-001
Target release posture	Internal engineering review only
Planned review environment	LMU-COICP Internal Engineering Review Environment
Planned dataset	Spring Semester Synthetic Incident Dataset
Planned synthetic records	421
Planned reviewer accounts	24
Planned review window	March 18–22, 2026
AI Incident Summary	Deferred / disabled
Operational pilot	Not approved

Integrated baseline under test

The ES-108 integrated baseline includes:

• IncidentRecord entity;
• EvidenceEvent entity;
• create synthetic incident workflow;
• partial status and handoff update workflow;
• basic access-control checks;
• validation and error behavior;
• emergency/out-of-scope category handling;
• AI Incident Summary deferment;
• manual workflow without AI.

Recommended workflow

Test Strategy
      ↓
Test Plan
      ↓
Test Cases
      ↓
Verification Matrix
      ↓
Test Execution Record
      ↓
Defect Log
      ↓
Guardrail Verification
      ↓
AI Verification Record
      ↓
Regression Check Record
      ↓
Testing Readiness Summary
      ↓
ES-110 Release Readiness

Repository location

docs/examples/lmu-coicp/testing/

In a project workspace, the comparable evidence would normally live under:

docs/project-workspace/testing/

Example set

01

Test Strategy

Define the LMU verification strategy for evidence, access, workflow, emergency-boundary, AI deferment, and regression risks.

02

Test Plan

Define test scope, owners, environment, phases, entry criteria, exit criteria, and evidence expectations.

03

Test Cases

Define executable checks using LMU synthetic incidents and reviewer roles.

04

Verification Matrix

Map LMU requirements, guardrails, and risks to test cases, results, evidence, and gaps.

05

Test Execution Record

Record what passed, failed, was partial, or was blocked.

06

Defect Log

Record DEF-001 through DEF-005 and their release-readiness implications.

07

Guardrail Verification

Verify evidence, access, emergency-boundary, retention, direct-update, and AI guardrails.

08

AI Verification Record

Confirm AI Incident Summary is deferred/disabled and future AI testing remains blocked.

09

Regression Check Record

Confirm core behavior remained stable after integration.

10

Testing Readiness Summary

Summarize testing evidence and hand off to Release Readiness.

LMU Testing Boundary

Testing supports release-readiness evaluation, not pilot approval. The right ES-109 outcome is honest evidence: normal-path confidence, open defects, and explicit release blockers.

Begin with Test Strategy

Start by reviewing how LMU verifies the integrated baseline before release-readiness review.

Open Test Strategy →