GAISSF DOCUMENTATION
Troubleshooting Guide
Public GAISSF v1.0 publication reproduced as accessible HTML from the final source document.
GAISSF™ v1.0
Troubleshooting Guide
Issue Diagnosis, Corrective Action, Recovery and Verified Resolution
| Field | Value |
|---|---|
| Document ID | GAISSF-IMP-016 |
| Version | 1.0 |
| Status | Final Publication v1.0 |
| Classification | Implementation guidance — informative |
| Publisher | ODA3 Institute |
| Legal entity | ODA3 Pvt Ltd |
| Authoritative normative source | GAISSF-NOR-001 |
| Control baseline | 59 controls across nine domains |
| Publication date | 29 June 2026 |
This guide provides practical issue-resolution methods. It does not replace emergency procedures, legal obligations, specialist safety engineering, incident-response plans or the normative GAISSF control requirements.
Document Control
| Attribute | Controlled value |
|---|---|
| Title | GAISSF™ v1.0 Troubleshooting Guide |
| Document ID | GAISSF-IMP-016 |
| Purpose | Provide a structured method for diagnosing, containing, correcting and verifying common GAISSF implementation and operational problems |
| Primary audience | Control owners, AI engineers, MLOps, DevSecOps, architects, security operations, incident response, risk, compliance, safety teams, assessors and program leads |
| Dependencies | GAISSF-NOR-001 through GAISSF-NOR-008 and GAISSF-IMP-009 through GAISSF-IMP-015 |
| Classification | Informative implementation guidance |
| Precedence | GAISSF-NOR-001, GAISSF-NOR-004, approved incident procedures and legal obligations prevail |
| Distribution | Public — Website and GitHub |
Legal and Reliance Notice
© 2026 ODA3 Pvt Ltd. Published market-facing by ODA3 Institute.
GAISSF™ is used as a framework mark. Third-party names and marks remain the property of their respective owners.
This guide does not constitute legal, regulatory, safety, engineering, certification or audit advice. It does not create a legal safe harbour, establish a legal standard of care, or determine statutory compliance in any jurisdiction.
Where human safety, unlawful processing, active compromise or irreversible action is possible, containment and specialist escalation take precedence over routine troubleshooting.
1. How to Use This Guide
Use the guide after confirming that the issue falls within the approved troubleshooting authority of the team. For material incidents, physical-safety events, suspected compromise, unlawful processing or major certification misstatement, activate the relevant incident, legal or safety procedure first.
Each issue pattern identifies symptoms, probable causes, immediate actions, verification and escalation criteria. Resolution is not complete until the corrective action is tested, evidence is preserved, related controls are reviewed and recurrence risk is assessed.
2. Troubleshooting Principles
| Principle | Application |
|---|---|
| Contain before optimizing | Stop or restrict harmful behavior before attempting performance tuning. |
| Preserve evidence | Do not destroy logs, model versions, prompts, outputs, state or physical telemetry while correcting the issue. |
| Reproduce safely | Use isolated test environments and representative data where possible. |
| Separate symptom from cause | A visible output failure may originate in data, policy, routing, identity, supplier or monitoring. |
| Verify the approved baseline | Confirm model, prompt, policy, tool, data and infrastructure versions before diagnosis. |
| Change one variable at a time | Avoid introducing multiple untracked fixes that obscure cause and evidence. |
| Retest related controls | A failure in one component may invalidate other control evidence. |
| Document uncertainty | Record when root cause is unknown or only partially supported. |
3. Severity and Response Model
| Severity | Example condition | Response expectation |
|---|---|---|
| S1 — Critical | Active compromise, physical danger, major unlawful disclosure, uncontrolled autonomous action | Immediate containment, incident command and executive/specialist escalation |
| S2 — High | Material control failure, repeated harmful output, major monitoring blind spot, failed rollback | Urgent restriction, investigation and risk-owner decision |
| S3 — Moderate | Degraded control, incomplete evidence, recurring noncritical alert, partial mapping defect | Time-bound corrective action and control-owner review |
| S4 — Low | Documentation defect, minor usability issue, isolated non-material mismatch | Normal improvement workflow |
4. Standard Diagnostic Workflow
- Confirm the issue and affected scope.
- Classify severity and determine whether incident or safety procedures apply.
- Preserve evidence and establish the last known good state.
- Contain or restrict affected capability.
- Compare the current state with the approved baseline.
- Identify candidate causes across people, process, technology, data and suppliers.
- Reproduce the problem safely where appropriate.
- Implement the least disruptive corrective action.
- Validate recovery and retest affected controls.
- Document root cause, limitations, evidence and recurrence prevention.
5. Root-Cause Analysis Methods
| Method | Best use | Caution |
|---|---|---|
| Five Whys | Simple recurring process or ownership failures | May oversimplify complex technical causes |
| Fault tree | Safety, infrastructure and multi-cause failures | Requires disciplined event definitions |
| Timeline reconstruction | Incidents, unauthorized changes and agent actions | Depends on complete and synchronized logs |
| Change comparison | Failures appearing after release or configuration update | May miss latent conditions |
| Control-path analysis | Bypasses, policy failures and missing enforcement | Requires accurate architecture |
| Data lineage analysis | Poisoning, leakage, drift and retrieval defects | Supplier data may be opaque |
| Hypothesis testing | Complex model behavior and intermittent faults | Avoid changing multiple variables simultaneously |
6. Governance and Scope Problems
6.1 Control has no clear owner
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Tasks are delayed; evidence is missing; multiple teams assume another team is responsible. | RACI not approved; control split across functions; organizational change; owner lacks authority. | Assign interim accountable owner; map operating roles; escalate authority gaps; update control register. | Owner accepts accountability; recurring activities and evidence are assigned; escalation path works. | No function accepts ownership or material risk remains unmanaged. |
6.2 Scope is inconsistent across documents
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Inventory, SoA, architecture and certificate claims describe different systems or boundaries. | Uncontrolled scope changes; multiple source lists; unclear supplier boundary; outdated diagrams. | Freeze current scope; reconcile system inventory, data flows, suppliers and claims; issue controlled scope record. | All artifacts use the same boundary and identifiers; excluded elements have approved rationale. | Public claims or certification status may be misleading. |
6.3 Foundational profile implemented incorrectly
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Teams omit all D9 controls or use 45/52 controls without an approved profile register. | Reliance on superseded drafts; informal interpretation; incomplete SoA. | Stop profile claims; use the controlled 52-control profile; reconcile all 59 controls and seven exclusions. | SoA matches the approved profile and all nine domains are considered. | Certification, customer claims or assurance reports relied on the incorrect scope. |
6.4 Exception has expired or become permanent
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Deviation remains open beyond expiry; compensating controls are untested; no remediation progress. | Weak governance; no automated reminders; risk owner unavailable; exception treated as normal. | Escalate; reassess risk; restrict affected use if necessary; renew only with new evidence and authority. | New decision, expiry, monitoring and remediation are recorded. | Risk exceeds delegated authority or control failure is material. |
7. Inventory, Configuration and Change Problems
7.1 Shadow AI or unknown system discovered
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Unregistered model/API use, browser extensions, local tools or embedded AI functionality appears. | Procurement bypass; weak discovery; unmanaged SaaS; developer experimentation. | Identify users, data and actions; restrict access if needed; add to inventory; assess scope and risk. | System is approved, contained or removed; data exposure and evidence are reviewed. | Sensitive data, consequential action or external disclosure occurred. |
7.2 Deployed model version does not match approval
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Behavior differs from test results; provider changed model; registry and runtime disagree. | Automatic provider update; unpinned version; release bypass; stale documentation. | Freeze deployment; identify actual version; compare behavior; revert or re-evaluate. | Runtime, registry, evidence and release record align. | Unknown provider change affects high-risk operation or cannot be reversed. |
7.3 Configuration drift detected
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Policies, prompts, tools, thresholds or infrastructure differ from approved baseline. | Manual edits; emergency changes; weak configuration management; environment mismatch. | Capture current state; block further change; compare baseline; restore or approve through change control. | Drift is eliminated or formally accepted; regression tests pass. | Drift bypassed security, safety or evidence controls. |
7.4 Rollback package is unavailable or unusable
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Last known good version cannot be restored; dependencies or data schema changed. | Incomplete release package; retention failure; untested rollback; supplier dependency. | Restrict new activity; reconstruct known-good state; create emergency recovery plan; test in isolation. | Rollback or safe degradation works and evidence is preserved. | Service cannot be safely contained or irreversible actions continue. |
8. Data, Retrieval and Privacy Problems
8.1 Sensitive data appears in model output
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| PII, confidential data, secrets or restricted content is reproduced. | Training memorization; retrieval authorization failure; prompt leakage; logging exposure. | Stop affected output path; preserve evidence; identify source; revoke access; notify privacy/incident teams. | Leakage path is closed; affected data and users are assessed; regression tests pass. | Breach notification, legal reporting or material harm may apply. |
8.2 Retrieval returns unauthorized documents
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Users receive content outside role, tenant or purpose. | Authorization applied after retrieval; filter bypass; index contamination; shared cache. | Disable retrieval or affected index; correct pre-retrieval authorization; clear contaminated caches. | Negative-access tests pass across tenants and roles. | Cross-tenant or regulated-data exposure occurred. |
8.3 Knowledge base is stale or inconsistent
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Answers cite outdated policy; different users receive conflicting information. | Failed indexing; missing freshness metadata; duplicate sources; delayed synchronization. | Identify authoritative source; re-index; expire old content; add freshness and precedence rules. | Outputs use current approved sources and show correct citations. | Outdated information caused consequential action or compliance risk. |
8.4 Data poisoning suspected
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Unexpected behavior follows data-source change; anomalies cluster around new records. | Untrusted source; compromised pipeline; malicious document; weak provenance. | Quarantine source; stop affected training/retrieval; preserve lineage; compare before/after behavior. | Source integrity is restored; model/index is rebuilt or validated; tests pass. | Poisoning affects production decisions, safety or multiple systems. |
8.5 Data drift alert is persistent
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Input or embedding distributions remain outside baseline; false alarms recur. | Real population change; monitoring defect; seasonal behavior; pipeline change. | Validate signal quality; segment by population; compare business context; adjust only with approval. | Threshold and response remain justified; model performance and risk are reassessed. | Drift affects fairness, safety, legal obligations or critical decisions. |
9. Model Behavior and Output Problems
9.1 Harmful or prohibited output increases
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Safety filters trigger more often; users report abuse; refusal behavior changes. | Model/provider change; policy drift; adversarial campaign; new use context. | Restrict affected capability; compare model and policy versions; increase review; run targeted evaluation. | Harm rate returns within approved limits and regression evidence is recorded. | Severe harm, repeated bypass or vulnerable populations are affected. |
9.2 Hallucination or unsupported answers remain high
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Confident incorrect answers; missing citations; conflicting evidence. | Poor grounding; retrieval failure; ambiguous task; excessive temperature; unsupported use case. | Constrain task; require citations; improve retrieval; lower randomness; add abstention and human review. | Representative tests meet approved accuracy and abstention criteria. | Errors create legal, medical, financial, safety or material business consequences. |
9.3 Refusal rate is too high
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Legitimate requests are blocked; users route around controls. | Overbroad policy; model change; poorly calibrated classifier; context loss. | Sample false refusals; refine policy boundaries; retrain or calibrate; maintain blocked harmful cases. | Legitimate completion improves without increasing unsafe output. | Users create uncontrolled workarounds or critical service is impaired. |
9.4 Model extraction or abnormal querying suspected
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| High-volume systematic queries; repeated boundary probing; unusual similarity requests. | Credential abuse; automated scraping; weak rate limits; exposed endpoint. | Rate-limit, revoke credentials, isolate account, preserve traffic, review output leakage. | Attack pattern stops; access and monitoring controls are improved. | Proprietary model, sensitive data or broad customer exposure is at risk. |
9.5 Model performance differs by group
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Error, refusal or harmful-output rates vary materially across populations. | Unrepresentative data; label bias; deployment context; threshold choice. | Segment evaluation; confirm data and outcome definitions; involve legal/ethics owners; redesign or restrict use. | Differences are understood, mitigated and monitored with approved criteria. | Protected groups, rights or high-impact decisions are affected. |
10. Prompt Injection and Adversarial Problems
10.1 Direct prompt injection bypasses policy
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| User instructions override system rules; prohibited tools or outputs become available. | Prompt-only control; weak instruction hierarchy; missing policy enforcement. | Disable high-risk tools; enforce external policy gate; add input classification and adversarial tests. | Injection scenarios fail safely and policy decisions are logged. | Consequential actions or sensitive data were exposed. |
10.2 Indirect injection from documents or web content
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Retrieved content changes agent behavior or requests tool actions. | Untrusted instructions treated as authority; no content isolation; overpowered agent. | Quarantine content; separate data from instructions; constrain tools; require approval. | Malicious document tests cannot alter policy or trigger unauthorized action. | External content caused transactions, data disclosure or persistent compromise. |
10.3 Jailbreak test results are inconsistent
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Same test passes and fails across runs; teams dispute severity. | Non-determinism; model version drift; incomplete test harness; inconsistent settings. | Fix versions and parameters; repeat statistically; record prompts, seeds and environment. | Results are reproducible enough for decision and limitations are documented. | High-risk bypass is observed even intermittently. |
10.4 Multi-modal input bypasses safeguards
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Text controls work but images, audio or files trigger unsafe behavior. | Modality-specific parser or classifier gap; unscanned attachments. | Restrict modality; scan and normalize input; test cross-modal attacks; align policies. | Equivalent policy outcomes apply across supported modalities. | Unsafe action or data extraction occurred. |
11. Agentic AI Problems
11.1 Agent enters a loop or fails to terminate
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Repeated tool calls, rising cost, duplicate actions or stalled workflow. | No step limit; ambiguous goal; tool failure; recursive delegation. | Activate circuit breaker; revoke credentials; preserve state; impose step/time limits. | Agent terminates predictably and duplicate actions are prevented. | Financial, operational or physical consequences continue. |
11.2 Agent performs unauthorized tool action
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Action exceeds user role, destination, value or approved objective. | Shared credential; missing action-level policy; confused deputy; injection. | Stop agent; revoke token; reverse action where possible; inspect approval and policy logs. | Per-agent identity and action authorization block recurrence. | Transaction is irreversible, regulated or materially harmful. |
11.3 Agent memory leaks between users
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| One user sees another user’s context or prior task data. | Shared memory namespace; tenant filter failure; cache contamination. | Disable memory; isolate tenants; purge affected state; assess disclosure. | Cross-user negative tests pass and retention/deletion rules work. | Personal, confidential or regulated information was exposed. |
11.4 Sub-agent delegation is untraceable
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Actions occur without clear parent, sponsor or permission chain. | Implicit delegation; shared identities; missing correlation IDs. | Suspend delegation; require parent-child identity and inherited permission limits. | Every action is attributable through the delegation chain. | High-impact actions cannot be reconstructed. |
11.5 Human approval is bypassed
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Agent executes before approval or approval is recorded after the fact. | Race condition; asynchronous queue; UI flaw; emergency override misuse. | Disable affected transaction; enforce server-side approval token; test timing and replay. | No action executes without valid pre-action approval. | Consequential or irreversible action occurred. |
12. Deployment and Platform Problems
12.1 Pilot succeeds but production fails
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Errors, harms or latency appear only after scale-up. | Pilot not representative; traffic, users, regions or data differ; hidden dependency. | Pause expansion; segment failures; compare pilot and production conditions; roll back if needed. | Representative load and scenario tests pass before re-expansion. | Material harm, outage or control failure persists. |
12.2 Canary metrics look healthy but users report problems
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Aggregate dashboards pass while specific groups or workflows fail. | Metrics too coarse; sampling bias; alert thresholds miss local impact. | Segment metrics; inspect complaints and traces; add outcome and user-impact measures. | Dashboard detects the previously hidden failure. | Vulnerable users or critical workflows are affected. |
12.3 Environment parity is broken
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Staging tests pass but production behavior differs. | Different model, policy, data, secrets, network or runtime configuration. | Compare manifests; align environments; record justified differences; repeat tests. | Production-relevant configuration is represented in validation. | Security or safety controls exist only in non-production. |
12.4 Feature flag enables unapproved capability
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Hidden feature becomes active without release approval. | Weak flag governance; default-on configuration; stale experiment. | Disable flag; audit changes and users; restrict permissions; require approval workflow. | Flag inventory, ownership and logging prevent recurrence. | Unapproved capability processed sensitive data or took actions. |
12.5 Supplier outage or silent service change
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Latency, behavior, refusal or output format changes unexpectedly. | Provider outage; model update; API change; region shift. | Activate fallback or degradation; compare provider notices; validate output and risk. | Service returns to approved baseline or migration is completed. | No safe fallback exists for critical operation. |
13. Monitoring and Evidence Problems
13.1 Monitoring blind spot discovered
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Actions cannot be reconstructed; required events are missing. | Logging disabled; unsupported provider; pipeline failure; privacy over-filtering. | Restrict high-risk operation; restore telemetry; identify affected period; document uncertainty. | End-to-end event coverage and alerting are tested. | The missing period includes incident, high-risk action or certification evidence. |
13.2 Alert volume overwhelms operators
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Backlog grows; acknowledgements are delayed; critical alerts are missed. | Poor thresholds; duplicate sources; no risk prioritization; noisy model behavior. | Prioritize by harm; suppress duplicates; tune with evidence; add ownership and service levels. | Actionable alert rate and response time improve without masking true positives. | Critical events are unreviewed or staffing is inadequate. |
13.3 Evidence is stale or incomplete
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Assessment cannot confirm current operation; artifacts refer to old versions. | Manual collection; unclear owner; change not linked to evidence refresh. | Identify affected controls; refresh evidence; automate capture; update expiry rules. | Evidence matches current scope, version and period. | Certification or customer claims relied on invalid evidence. |
13.4 Evidence conflicts across sources
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Dashboard says control passed while logs or test results show failure. | Different periods; metric aggregation; source tampering; definition mismatch. | Freeze conclusion; reconcile timestamps, scope and definitions; preserve all versions. | A single supported conclusion and limitation record are approved. | Conflict indicates manipulation or material control failure. |
13.5 Failed test result was removed or altered
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Negative evidence is missing; report history differs from repository. | Pressure to pass; weak access control; manual overwrite. | Preserve repository; restrict access; investigate integrity; restore audit trail. | All results and changes are attributable and immutable enough for assurance. | Intentional evidence manipulation or certification misstatement is suspected. |
14. Incident, Recovery and Continuity Problems
14.1 Incident severity is disputed
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Teams disagree whether to escalate; response is delayed. | No AI-specific severity criteria; unclear affected persons or consequence. | Use worst credible impact; convene security, safety, legal and system owners; document decision. | Severity and authority are agreed and response times are met. | Delay may increase harm or reporting deadlines are uncertain. |
14.2 Root cause remains unknown
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| System is restored but no supported explanation exists. | Incomplete logs; supplier opacity; non-determinism; multiple concurrent changes. | Document unknown cause; increase monitoring; restrict risk; run structured hypotheses. | Residual uncertainty is accepted by proper authority and recurrence controls exist. | High-severity risk cannot be bounded. |
14.3 Recovery restores service but not controls
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| System is available but monitoring, policy or evidence remains degraded. | Recovery focused only on uptime; incomplete runbook. | Keep service restricted; validate each critical control before full return. | Control-health and evidence checks pass, not only functional tests. | High-risk operation resumes without assurance. |
14.4 Incident evidence cannot be synchronized
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Prompts, tool calls, logs and physical telemetry have inconsistent timestamps. | Clock drift; missing correlation IDs; separate supplier systems. | Preserve original records; establish offset; use sequence and transaction identifiers. | Timeline is sufficiently reliable and limitations are recorded. | Legal, safety or fraud investigation requires precise reconstruction. |
15. Physical AI Problems
15.1 Emergency stop does not work as expected
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Stop command is delayed, ignored or dependent on the AI controller. | Shared failure path; maintenance defect; inaccessible interface. | Enter alternate safe state; remove system from service; activate safety incident process. | Independent stop is repaired and tested under realistic conditions. | Any person may be exposed to harm. |
15.2 System leaves approved operational envelope
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Speed, location, force, load or environmental limits are exceeded. | Planner error; sensor fault; stale map; safety supervisor bypass. | Stop or restrict system; preserve telemetry; inspect supervisor and sensor data. | Envelope enforcement blocks recurrence and safe recovery is tested. | Actual or near-miss physical harm occurred. |
15.3 Sensor disagreement causes unstable behavior
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Rapid switching, erratic motion or inconsistent perception. | Calibration drift; obstruction; time synchronization; sensor compromise. | Reduce capability or stop; isolate faulty sensor; use validated fallback or voting. | Fault detection and degraded mode perform as designed. | Safe operation cannot be demonstrated. |
15.4 Safe state cannot be reached
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| System remains active or creates new hazards during failure. | Poor safe-state design; energy or mechanical constraint; software-only assumption. | Activate emergency procedure; isolate energy; involve specialist safety authority. | Safe-state transition is redesigned and physically tested. | Immediate danger exists or fail-safe assumptions are invalid. |
15.5 Physical incident evidence is incomplete
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Cannot reconstruct commands, sensor state, overrides or actuator response. | Insufficient telemetry; storage loss; unsynchronized systems. | Preserve hardware and available logs; photograph state; obtain supplier records. | Future events record synchronized safety-relevant data. | Investigation, reporting or liability may be affected. |
16. Assessment and Certification Problems
16.1 Assessment finding is challenged
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Control owner disputes evidence or interpretation. | Scope mismatch; incomplete sampling; ambiguous criterion; missing context. | Separate factual and interpretive issues; review exact requirement, scope and evidence. | Decision and rationale are documented through approved review or appeal route. | Independence, fairness or certificate status is affected. |
16.2 Certification scope is misstated publicly
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Marketing implies enterprise-wide or higher-profile coverage than certificate. | Poor claims review; vague wording; outdated certificate. | Correct or withdraw claim; notify certification authority if required; preserve evidence. | All public statements match version, profile, scope and status. | Customers, regulators or investors may have relied on the claim. |
16.3 Crosswalk is treated as proof of conformance
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Teams close GAISSF controls based only on ISO/NIST/OWASP mapping. | Confusion between relationship and implementation; evidence not reassessed. | Reopen controls; test scope and operating effectiveness; classify mapping limitations. | Each GAISSF control has direct implementation and evidence. | Certification readiness or compliance claims rely on unsupported closure. |
16.4 Surveillance evidence period is insufficient
| Symptoms | Likely causes | Immediate actions | Verification | Escalate when |
|---|---|---|---|---|
| Current records do not cover the required operating period. | Recent implementation; evidence loss; late scope change. | Defer claim or assessment; extend evidence period; use limited scope only if valid. | Required period is represented and stable operation is demonstrated. | Certificate continuation would be misleading. |
17. Decision Trees
| Question | Yes | No |
|---|---|---|
| Could the issue cause immediate human harm? | Stop/enter safe state and activate safety response | Continue severity assessment |
| Is active compromise or unauthorized action occurring? | Contain, revoke access and activate incident response | Continue diagnosis |
| Is sensitive or regulated data exposed? | Restrict processing and involve privacy/legal | Continue technical troubleshooting |
| Can the issue be reproduced safely? | Use isolated environment and controlled variables | Rely on evidence, simulation and bounded hypotheses |
| Is the last known good state available? | Rollback or compare directly | Construct recovery baseline and restrict operation |
| Does evidence show the fix worked? | Retest related controls and close formally | Do not close; revise corrective action |
18. Corrective Action and Closure
| Closure criterion | Required evidence |
|---|---|
| Containment effective | Harmful or uncontrolled behavior has stopped |
| Root cause supported | Evidence supports the cause, or uncertainty is explicitly accepted |
| Corrective action implemented | Change record, configuration, code, process or training evidence |
| Regression passed | Original failure and related scenarios no longer reproduce |
| Control retested | Affected GAISSF controls return to approved state |
| Scope reviewed | Related systems, suppliers and populations assessed |
| Evidence preserved | Original and corrected-state records retained |
| Owner approval | Control and risk owners accept closure |
| Prevention established | Monitoring, design or workflow reduces recurrence |
19. Troubleshooting Metrics
| Metric | Purpose | Caution |
|---|---|---|
| Mean time to contain | Assess ability to limit harm | Measure by severity and system type |
| Mean time to diagnose | Assess observability and expertise | Unknown root cause may be honest |
| Repeat issue rate | Detect weak corrective action | Normalize by system and volume |
| Rollback success rate | Assess recovery readiness | A rollback may still lose data or transactions |
| Evidence completeness | Assess reconstructability | Artifact count is not quality |
| Alert-to-incident conversion | Assess alert usefulness | Low rate may reflect under-escalation |
| Corrective-action overdue rate | Assess governance discipline | Prioritize by risk, not count alone |
20. Common Troubleshooting Anti-Patterns
| Anti-pattern | Why it fails | Required correction |
|---|---|---|
| Restart and forget | Removes symptom without preserving cause | Preserve evidence and complete root-cause review |
| Tune thresholds until alerts disappear | Can hide real failures | Validate signal and risk before adjustment |
| Patch only the visible output | Underlying data or control path remains broken | Review end-to-end control chain |
| Close when service returns | Controls and evidence may remain degraded | Require control-health verification |
| Blame the model provider immediately | Local integration may be the cause | Compare supplier and local evidence |
| Delete failed tests | Destroys assurance integrity | Retain and explain all results |
| Fix directly in production | Creates uncontrolled change and weak evidence | Use emergency change only with authority and rollback |
| Assume one incident is isolated | Systemic weakness may persist | Assess related systems and controls |
21. Limitations
- The issue patterns are not exhaustive and cannot replace specialist investigation.
- Some failures cannot be reproduced because of non-determinism, supplier opacity or missing telemetry.
- A successful fix does not prove that all related risks are eliminated.
- Physical-AI troubleshooting may require qualified safety engineers and controlled test facilities.
- Legal and regulatory reporting obligations may apply before root cause is known.
22. Notably Absent
- No universal severity threshold for every AI system.
- No permission to delay emergency containment while completing diagnosis.
- No guarantee that rollback restores all data, transactions or physical state.
- No assumption that absence of alerts means absence of failure.
- No approval to alter evidence, hide failed tests or suppress material findings.
- No substitution for legal advice, incident command or specialist safety authority.
Annex A — Troubleshooting Record Template
| Field | Entry |
|---|---|
| Issue ID | |
| Date/time | |
| System/scope | |
| Reporter | |
| Severity | |
| Symptoms | |
| Containment | |
| Evidence preserved | |
| Baseline compared | |
| Hypotheses | |
| Root cause | |
| Corrective action | |
| Verification | |
| Related controls | |
| Residual risk | |
| Approver | |
| Closure date |
Annex B — Root-Cause Worksheet
| Category | Questions | Findings |
|---|---|---|
| People | Were roles, competence, authority or handoffs inadequate? | |
| Process | Did workflow, approval, change or escalation fail? | |
| Technology | Did model, code, platform, policy or integration fail? | |
| Data | Were provenance, quality, access, drift or retention defective? | |
| Supplier | Did an inherited control, service or notification fail? | |
| Environment | Did scale, geography, physical context or threat change? |
Annex C — Verification Checklist
☐ Original issue no longer reproduces under representative conditions
☐ Containment can be removed safely
☐ Affected control evidence is current
☐ Related systems and suppliers were assessed
☐ Monitoring detects recurrence
☐ Rollback or safe state remains available
☐ Residual risk is approved
☐ Users and stakeholders were informed where required
☐ Corrective action is documented and closed
Annex D — Escalation Matrix Template
| Condition | Primary authority | Secondary authority | Target response | Required evidence |
|---|---|---|---|---|
| Physical danger | Safety authority | Executive/incident command | ||
| Active compromise | Security incident lead | System owner/legal | ||
| Data exposure | Privacy/legal | Security/system owner | ||
| Agent unauthorized action | System owner | Security/risk | ||
| Certification misstatement | Certification/legal | Executive/communications | ||
| Control evidence failure | Control owner | Internal assurance/risk |
Annex E — Source Traceability
| Troubleshooting subject | Controlled source |
|---|---|
| Normative controls | GAISSF-NOR-001 and GAISSF-NOR-004 |
| Terminology | GAISSF-NOR-005 |
| Release and correction status | GAISSF-NOR-007 and GAISSF-NOR-008 |
| Adoption governance | GAISSF-IMP-009 |
| Implementation workflows | GAISSF-IMP-010 |
| Deployment and rollback | GAISSF-IMP-011 |
| Migration and evidence reuse | GAISSF-IMP-012 |
| Architecture and trust boundaries | GAISSF-IMP-013 |
| Operations and monitoring | GAISSF-IMP-014 |
| Common interpretation | GAISSF-IMP-015 |
Annex F — Publication Record
| Version | Date | Change | Status |
|---|---|---|---|
| 1.0 | 29 June 2026 | Initial full troubleshooting guide for GAISSF v1.0 | Final Publication v1.0 |
Legal and Regulatory Integration
GAISSF provides an operational security, safety, governance and evidence framework. It does not determine which laws apply, establish statutory compliance, create a legal safe harbour, define a legal standard of care, replace competent legal advice, or guarantee that evidence collected for GAISSF purposes will satisfy a regulator, court or other authority. Organizations should maintain a jurisdiction-specific legal and regulatory obligations register and map applicable obligations to their GAISSF scope, controls, evidence, reporting processes and decision authorities.
Legal and regulatory interface requirements
- Identify applicable jurisdictions, regulators, sector rules, contractual duties and internal legal authorities before relying on this guide.
- Maintain a controlled obligations register, reporting-clock register, retention schedule, legal-hold process and conflicts-of-obligation procedure.
- Treat statutory, regulatory and contractual analysis as a parallel workstream to GAISSF implementation and assurance.
- Record the legal basis, responsible owner, scope, decision, evidence, deadline and review date for each material obligation.
- Do not represent GAISSF conformance, maturity or certification as legal approval, permission to operate, immunity from enforcement or proof that harm cannot occur.
How to use this document
| Reader | Recommended use |
|---|---|
| Executive or board reader | Review purpose, decision rights, legal and regulatory integration, limitations and Notably Absent sections. |
| Program or control owner | Use workflows, templates, gates, evidence fields and escalation criteria as implementation aids. |
| Engineering or operations team | Translate guidance into system-specific procedures, configurations, runbooks and testable acceptance criteria. |
| Legal, privacy or compliance team | Validate jurisdiction-specific obligations, deadlines, retention, disclosure, privilege and regulator-facing requirements. |
| Assessor or auditor | Use the document as informative context only; test claims against the authoritative normative sources and applicable assessment criteria. |
See Also
- Approved incident, safety, legal and regulatory procedures.
- GAISSF-IMP-014 for operations.
- GAISSF-IMP-017 for evidence preservation.
Troubleshooting-specific regulatory enhancements
Preservation-aware pre-change checkpoint
- Determine whether litigation, enforcement, investigation or a preservation duty is pending or reasonably anticipated.
- Check for active legal holds, regulator instructions, consent orders or change restrictions.
- Identify whether reboot, scaling, redeployment, cache clearing, log rotation or instance termination could destroy relevant evidence.
- Acquire forensic or evidentiary copies before destructive remediation where required.
- Record authorization for emergency changes and unavoidable evidence loss.
Technical containment versus legal preservation
Troubleshooting actions may create preservation risk where relevant evidence is destroyed after a duty to preserve has arisen. Technical containment and legal preservation should therefore be coordinated, but neither automatically overrides immediate life-safety or critical-service actions.
RCA governance and privilege caution
For severe events, organizations should determine with qualified counsel whether legal direction, separate factual and legal workstreams, distribution restrictions or other measures are appropriate. Counsel involvement does not by itself guarantee attorney-client privilege or work-product protection, and protection may vary or be waived.
Known-issues and failed-test repository
- Retain the original test script, harness configuration, raw result, environment log and failed output.
- Record verified fixes, applicable versions, side effects, recurrence indicators and evidence.
- Do not convert an unverified workaround into an approved baseline.
S1 response summary
| Action | Expectation |
|---|---|
| Contain | Isolate, disable or enter safe state as appropriate. |
| Notify | Activate incident, safety, legal and executive procedures. |
| Preserve | Capture volatile and persistent evidence before further change where feasible. |
| Escalate | Use designated specialist and regulatory authorities. |
| Validate | Retest affected controls before restoration. |
Notably Absent — legal and regulatory boundary
- No assertion that every loss of data is legally actionable spoliation.
- No guarantee of privilege from counsel involvement.
- No permission to alter systems contrary to regulator, court or consent-order restrictions.
Publication revision record
| Revision | Disposition |
|---|---|
| R2 — Regulatory and practitioner refinement | Added legal and regulatory integration, preservation, reporting, decision-record, public-claim and usability guidance. No normative GAISSF control was added, removed, renamed or amended. |
| Authority boundary | GAISSF-NOR-001, GAISSF-NOR-004 and controlled profile records remain authoritative. |