Unseen Operational Explainability Framework

Purpose

The Operational Explainability Framework defines how Unseen produces explainability artifacts for Salesforce environments.

Its purpose is simple:

When an operator, executive, auditor, or partner asks, "Why did Salesforce do that?", the institution should be able to answer from evidence rather than folklore.

Explainability is not a technical luxury. It is the operating layer that makes automation governable, supportable, and eventually safe for AI.

Framework Outputs

Every explainability initiative should produce four outputs:

1. an automation inventory
2. decision logic documentation
3. a support playbook for incident response
4. an explainability audit checklist and score

1. Automation Inventory Standard

Every automation affecting a revenue-critical object should be documented to a common standard.

Required documentation fields

Standard classification tags

Each automation should also carry:

• criticality: low, medium, high, mission-critical
• reversibility: easy, bounded, hard, non-reversible
• action type: notify, enrich, route, update, approve, orchestrate
• explainability status: fully explainable, partially explainable, opaque

2. Decision Logic Documentation Template

Use the template below for any automation or AI-supported decision path that materially changes business state.

Template

Artifact name:
[Automation or decision name]

Business purpose:
What business outcome is this logic intended to produce?

Trigger:
What event, user action, schedule, or system signal starts it?

Records and fields used:
Which objects and fields are read? Which are required? Which are considered advisory only?

Decision rule:
Describe the rule in plain language first. Then include the exact condition logic or reference the implementation source.

Exception handling:
What known exceptions exist? When should the logic stop, escalate, or defer to a human?

Side effects:
What additional automation, approvals, notifications, integrations, or record changes can this decision trigger?

Failure modes:
How can this logic fail, misclassify, or create unintended consequences?

Owner and approver:
Who owns the rule? Who approved the current behavior?

Last validation date:
When was the logic last reviewed against current business policy?

How to explain this to operations:
One short paragraph answering, "Why did the system do this?"

3. "Why Did Salesforce Do That?" Response Playbook

This playbook is for frontline operations, admins, and support teams handling confusing system behavior.

Step 1: Capture the event

• record ID
• timestamp
• acting user or integration
• changed fields
• visible downstream actions

Step 2: Trace the likely cause set

Review:

• active automations on the object and event
• recent human edits and integration writes
• approvals, assignment rules, validation rules, and Apex side effects
• scheduled jobs or asynchronous paths in the relevant time window

Step 3: Determine the explanation class

Classify the event as one of:

• expected documented behavior
• expected but poorly understood behavior
• undocumented legacy logic
• conflicting automation
• data-quality induced behavior
• permission or ownership anomaly
• external-system side effect

Step 4: Respond in business language

The first answer should not be metadata jargon. It should explain:

• what condition caused the behavior
• what the system attempted to achieve
• whether the result was correct, incorrect, or uncertain
• what the next action is

Step 5: Close the explainability loop

If the issue was not clearly documented:

• create or update the explainability artifact
• assign an owner
• determine whether the gap is local or systemic
• add the issue to the governance or remediation backlog

Standard Response Format

Use this response structure for operations teams:

1. What happened: The record changed in a specific way.
2. Why it happened: The system evaluated a specific rule or dependency.
3. Whether it was intended: Confirmed, unintended, or still under review.
4. What happens next: Reverse, accept, escalate, or remediate the underlying logic.

4. Explainability Audit Checklist

Use this 20-item checklist to test whether a Salesforce environment is explainable enough to support scale, governance, and AI.

Reading The Checklist

• 16-20 yes answers: explainability is a governance strength
• 11-15 yes answers: explainability is emerging but still uneven
• 6-10 yes answers: the org is operationally opaque in important areas
• 0-5 yes answers: the org cannot reliably explain its own behavior

How This Connects To Unseen's Work

The explainability framework is the artifact layer between audit and governance:

• Stage 1 Audit identifies what exists
• Stage 2 Living Documentation captures how it works
• Stage 3 Monitoring reveals what changes
• Stage 4 Governance assigns control
• Stage 5 AI Readiness uses explainability as a deployment precondition

Without explainability artifacts, every future automation and AI decision is being made on partial institutional memory.