Cross-Cutting Domains¶

Some domains do not start with one asset or one protocol. They cut across charging, vehicles, energy, work, commercial state, and users. These domains are still decision owners, so they need clear coordinates.

This module covers:

• Incidents & Notifications
• Reporting & Insights
• Resilience & Security
• Accessibility & Usability

Cross-Cutting Flow¶

flowchart TB
  subgraph Evidence["Evidence sources"]
    Charger["charger status and meter evidence"]
    Vehicle["vehicle activity"]
    Work["work and schedule state"]
    Energy["energy system state"]
    Commercial["commercial and payment state"]
    User["user actions and support context"]
  end

  subgraph CrossCutting["Cross-cutting domain decisions"]
    Detect["Detection<br/>is something abnormal?"]
    Alert["Alerting<br/>who needs to know?"]
    Resolve["Resolution<br/>what should happen next?"]
    Report["Reporting<br/>what happened and why?"]
    Trust["Trust and safety<br/>who or what may act?"]
    Usability["Usability and support<br/>can the user understand and recover?"]
  end

  subgraph Outputs["Product outputs"]
    OpsView["operational dashboard"]
    IncidentTimeline["incident timeline"]
    ControlGuard["safe fallback or blocked action"]
    ReportRow["report row or export"]
    HelpPath["help article or support case"]
    Audit["audit trail"]
  end

  Charger --> Detect
  Vehicle --> Detect
  Work --> Detect
  Energy --> Detect
  Commercial --> Detect
  User --> Trust
  User --> Usability
  Detect --> Alert
  Detect --> Resolve
  Detect --> Report
  Trust --> ControlGuard
  Trust --> Audit
  Usability --> HelpPath
  Alert --> OpsView
  Resolve --> IncidentTimeline
  Report --> ReportRow
  Report --> OpsView

Incidents & Notifications¶

Incident work owns abnormal-state detection, impact explanation, notification, and resolution workflow.

stateDiagram-v2
  [*] --> Observed
  Observed --> Detected: abnormal condition
  Detected --> Notified: alert policy matched
  Notified --> Investigating: owner accepts / system assigns
  Investigating --> Mitigated: workaround or control action
  Investigating --> Resolved: fault cleared
  Mitigated --> Resolved: durable fix
  Resolved --> Closed: evidence reviewed
  Detected --> Closed: false positive

Common domain question: is this a charger fault, vehicle readiness issue, energy constraint, schedule issue, platform health issue, or commercial access issue? The answer decides which domain owns the fix.

Reporting & Insights¶

Reporting owns derived history, analysis, proof, and accountability. It should read projections and preserve lineage back to the evidence.

flowchart LR
  Evidence["Raw evidence<br/>session, meter, schedule, telemetry, tariff"]
  Projection["Projection<br/>charging, vehicle activity, energy system, commercial record"]
  Metric["Metric<br/>readiness, uptime, cost, carbon, utilisation"]
  View["View<br/>dashboard, report, export"]
  Decision["Decision<br/>operate, bill, prove, improve"]

  Evidence --> Projection
  Projection --> Metric
  Metric --> View
  View --> Decision
  Projection -. lineage .-> View

Reporting should avoid re-deciding domain truth. For example, a report should read the readiness projection rather than recomputing readiness from raw session records in a separate way.

Resilience & Security¶

Resilience & Security owns trust, permissions, safe control, audit, fallback, and recoverability.

flowchart TB
  Actor["Actor<br/>user, system, charger, partner"]
  Identity["Identity and trust<br/>role, token, cert, contract"]
  Request["Requested action<br/>start, stop, profile, access, export"]
  Policy["Policy check<br/>permission, safety, freshness, scope"]
  Allowed["Allowed action<br/>with audit"]
  Denied["Denied or limited action<br/>reason and fallback"]
  Evidence["Audit evidence<br/>who, what, why, when"]

  Actor --> Identity
  Identity --> Request
  Request --> Policy
  Policy --> Allowed
  Policy --> Denied
  Allowed --> Evidence
  Denied --> Evidence

This domain should be reviewed whenever a feature can command power, grant access, expose commercial records, or change safety-critical fallback behaviour.

Accessibility & Usability¶

Accessibility & Usability owns the human path through complex domain state. It includes onboarding, support, UI clarity, and recovery.

flowchart LR
  DomainState["Domain state<br/>vehicle, charger, energy, incident, report"]
  Role["User role<br/>operator, energy manager, support, finance"]
  Task["Task<br/>decide, configure, recover, prove"]
  Surface["Surface<br/>screen, help doc, notification, report"]
  Outcome["Outcome<br/>user acts correctly with confidence"]

  DomainState --> Task
  Role --> Task
  Task --> Surface
  Surface --> Outcome

When user-visible behaviour changes, update the in-app help docs. When behind-the-scenes behaviour changes what users should expect or do, update help docs as well.

Coverage Check¶

Use this check before a spec or story is marked ready:

• Does the feature have one primary problem-domain coordinate?
• Which cross-cutting domains read or react to it?
• What incident or degraded state could happen?
• What report or audit trail needs the outcome?
• What trust, permission, or fallback rule applies?
• What user-facing explanation or help path changes?