Specification Exploration Dossier: Enable Scheduled Managed Charger Access

Source Inputs

• Challenge: challenge.md
• Existing artifacts:
• spec.md
• review.md
• Linear initiative: Enable Scheduled Managed Charger Access
• Repos / docs / links reviewed:
• bf-manage-connect/src/ocpp_handlers/v1_6/resolvers/authorize.py
• bf-manage-connect/src/ocpp_handlers/v2_0_1/resolvers/authorize.py
• bf-manage-connect/src/auth/charging_authentication_handler.py
• bf-manage-connect/src/ocpp_handlers/v1_6/auto_configuration/default_config.json
• bf-manage-core/src/api/transaction/router.py
• bf-manage-core/src/api/transaction/service_layer.py
• bf-manage-core/src/charging/transaction/transaction_auth.py
• bf-manage-core/src/api/charge_point/router.py
• bf-manage-core/src/charging/charge_point/charge_point_aggregate.py
• bf-manage-core/src/charging/vehicle/vehicle.py
• bf-manage-core/src/charging/vehicle/helpers.py
• bf-manage-core/src/vemo_core_common/db/migrations/versions/a042a7350f44_add_unique_constraint_to_account_ig_tag_.py
• bf-manage-core/src/incidents/types.py
• bf-manage-core/src/incidents/error_info.json
• bf-manage-web/src/pages/Settings/DepotVehicles/VehiclesTab/VehicleSettingsSBC.tsx
• bf-manage-web/src/interfaces/vehicle.ts
• bf-manage-web/src/pages/MobileOps/Incidents.tsx
• bf-manage-web/src/pages/MobileOps/ChargerDetail.tsx
• bf-manage-core/src/interop_testing/protocols/ocppv16/packet_templates.py
• docs/decisions/adrs/0009-use-timezone-aware-datetimes-and-utc.md
• docs/decisions/adrs/0011-centralized-feature-flag-repository.md
• docs/decisions/adrs/0020-api-backwards-compatibility-and-versioning.md
• docs/decisions/adrs/0023-domain-event-driven-architecture.md
• Constraints:
• First useful scope must remain charger-level unless exploration proves another scope is required.
• Managed access must allow known own-fleet and agreement vehicles and deny unknown or unauthorised vehicles.
• Denials must be distinguishable from charger faults and incidents.
• Time handling must follow ADR 0009.
• API changes should prefer additive evolution.
• BetterFleet Manage feature rollout follows current GitLab Feature Flags / Unleash process, despite older ADR 0011 mentioning LaunchDarkly.

Current Understanding

• Problem:
• Operators need scheduled switching between open freevend periods and restricted managed-access periods.
• The current product has pieces of transaction authorisation and vehicle identifiers, but no explicit scheduled access policy model.
• Desired outcome:
• A charger can follow a recurring access schedule.
• During managed access, the charging attempt is allowed only when the presented identifier maps to an active allowed vehicle class.
• Denied attempts create a supportable access-control outcome rather than a fault-shaped incident.
• Likely solution direction:
• Reuse and harden the existing OCPP 1.6 authorisation path for the first vertical slice.
• Add explicit charger access policy state around the existing authorise_transactions concept rather than hiding policy in raw advanced settings.
• Create a separate access-decision record/read model before changing operations views.
• Treat freevend switching as a charger capability with explicit unsupported and partially supported states.
• Current baseline:
• OCPP 1.6 Authorize calls BetterFleet Core through /api/transaction/authorise.
• Core checks known vehicle identifiers and the charger authorise_transactions setting.
• Unknown identifiers can be blocked and published as unknown_vehicle_identifier incidents.
• OCPP 2.0.1 Authorize currently returns Accepted without calling Core.
• Freevend keys are known in interop test templates as FreevendEnabled and FreeVend, but no product-level scheduled mode model was found.
• Vehicle identifiers exist in Manage vehicle settings and are unique per account.
• Mobile Ops has charger detail and incident views that could become early operations surfaces.

Discovery Question Ledger

Question	Why it matters	Current assumption / evidence	Status	Spec impact
Which charger/protocol path is first?	Capability determines the first buildable slice and denial signal.	OCPP 1.6 has an authorisation path; OCPP 2.0.1 currently accepts all authorisations.	unanswered	Spec must name first supported path and capability states.
Can first chargers switch freevend remotely through known configuration keys?	Scheduled access mode needs a reliable mode-change mechanism.	Interop templates know FreevendEnabled and FreeVend; Core/Connect support configuration messages.	unanswered	Spec must define freevend apply/confirm/failure behavior.
Does authorise_transactions represent managed access, or is it just a low-level integration flag?	Product terms should not leak raw charger settings.	Existing advanced setting says BetterFleet authorises transactions based on depot rules and known identifiers.	assumed	Spec should map product access mode to underlying settings.
What owns own-fleet identifiers?	Managed access needs authoritative allow/deny classification.	Vehicle identifiers are stored as vehicle_identifier_mapping and managed in Depot Vehicles UI.	partially answered	Spec can treat own-fleet identifiers as existing Core vehicle data, pending lifecycle details.
What owns agreement vehicle identifiers?	Agreement access is required by the challenge but out of scope for agreement lifecycle.	No agreement identifier source found in local evidence.	unanswered	Spec must mark agreement identifiers as dependency or defer agreement vehicle access from first slice.
Should unknown identifier attempts stay incidents?	Challenge says denials should not be confused with charger failure.	Core currently publishes unknown identifier as an error incident.	unanswered	Spec likely needs an access-decision/event model separate from incidents.
Can raw identifiers be shown or stored?	Support needs explainability, but identifiers may be sensitive.	Current incident detail includes raw idTag; review called out masking/hashing.	unanswered	Spec must define raw, masked, and hashed identifier handling.
What happens when a charger is offline at a schedule boundary?	Access mode may drift from expected mode.	Existing charger detail has online/offline state and action disabled states.	unanswered	Spec needs expected vs observed mode states and recovery behavior.
What is the recurrence model?	UI, persistence, and tests depend on the allowed schedule shape.	Current docs only say recurring and timezone-aware.	unanswered	Spec must settle recurrence before story shaping.
Where should access denials appear first?	UI scope and delivery slices depend on surface choice.	Mobile Ops incidents and charger detail are existing operations surfaces.	unanswered	Spec must pick first visibility surface and report scope.
What rollout stage applies?	Delivery needs flag, docs, release, and support follow-through.	Manage feature-flag process applies to customer exposure.	unanswered	Spec must name rollout approach without raw public flag names.

Focus Map

Lane	Depth	Why	Suggested tools / skills
Frontend / UX	primary	Operators need schedule configuration; operations/support users need denial visibility.	react-typescript, screenshots/browser later, help-docs-authoring later
Backend / domain	primary	Access policy, schedule evaluation, identifier classification, and decision recording are domain-heavy.	bf-python-ddd-architecture, python-engineering later
Data / integration	primary	OCPP capability, freevend config, authorisation timeout, identifier storage, and audit records shape feasibility.	bf-python-ddd-architecture, charger/protocol owner input
Release / docs / rollout	secondary	User-visible behaviour changes and staged rollout are likely.	release-notes-writer, help-docs-authoring later
Delivery slicing	primary	Current spec is broad; a first vertical slice must avoid hiding agreement and protocol complexity.	story-shaper after spec rewrite

JTBD and Use-Case Exploration

• Personas / actors:
• Depot operator: configures when chargers are open or restricted.
• Operations user: monitors live charger state and charging attempts.
• Support user: investigates denied starts and explains policy outcomes.
• Fleet administrator: maintains own-fleet identifiers.
• Agreement administrator: maintains external fleet access identifiers.
• Driver: attempts to charge and receives whatever denial signal the charger can provide.
• Charger integration/system actor: applies configuration and asks for authorisation.
• Jobs to be done:
• Schedule open/restricted access in line with depot operating patterns.
• Confirm whether a charger is expected to be open, restricted, unsupported, or out of sync.
• Decide whether a presented identifier belongs to an allowed class.
• Record why charging was allowed or denied.
• Explain a denied attempt without treating it as equipment failure.
• Current pain/gain:
• Current access control appears tied to per-charger advanced settings and known identifiers.
• Unknown-identifier blocking exists, but the user-facing outcome is incident-shaped.
• Operators lack an explicit schedule-driven access model.
• Desired outcomes:
• Operators schedule policy once and then monitor exceptions.
• Support can distinguish policy denial from charger fault, communication failure, or missing card.
• Agreement access can be layered in without changing own-fleet access semantics.
• High-level use cases:
• Configure a recurring weekday managed-access window for a charger.
• Switch a charger to managed access at a scheduled boundary.
• Deny an unknown identifier during managed access and record the denial.
• Allow an own-fleet identifier during managed access.
• Show that a charger could not apply a scheduled mode because it is offline or unsupported.

Candidate Stories and Slices (Exploratory)

• Candidate story themes:
• Capability discovery and supported charger status.
• Own-fleet managed-access authorisation using existing identifiers.
• Access-denied decision recording separate from incidents.
• Scheduled access policy configuration and evaluation.
• Apply scheduled freevend/managed mode to one OCPP 1.6 charger path.
• Operations visibility for access decisions and mode-change problems.
• Agreement vehicle identifier integration.
• Candidate vertical slices:
• Slice 1: Make current own-fleet authorisation product-shaped.
  • For chargers with authorise_transactions=true, record allow/deny access decisions for OCPP 1.6 attempts using existing vehicle identifiers.
  • Keep schedule and freevend switching out of this slice.
• Slice 2: Add schedule configuration without physical mode switching.
  • Operators can define recurring charger access windows.
  • System derives expected access mode and exposes it.
• Slice 3: Apply scheduled mode to a supported OCPP 1.6 charger.
  • At boundaries, BetterFleet changes the relevant configuration and records success/failure.
• Slice 4: Add operations visibility.
  • Charger detail or a dedicated access-events view shows denied attempts and mode-change problems.
• Slice 5: Add agreement identifiers once the source system is confirmed.
• Split signals:
• Agreement vehicles are a separate slice unless an identifier source already exists.
• OCPP 2.0.1 is separate because its Authorize path currently accepts all identifiers.
• Driver-facing denial signal should trail protocol-specific validation.
• Manual overrides should trail recurring schedules unless operators need recovery before launch.
• Story-shaping risks:
• A story that includes schedule UI, freevend switching, OCPP config, identifier classification, denial visibility, and agreement vehicles will be too broad.
• A story that uses incidents as the only denial surface may fail the challenge outcome.
• A story that starts with agreement vehicles may block on upstream data ownership.

Example Mapping and BDD-Style Discovery

• Rules:
• Freevend mode allows charging without a BetterFleet access decision.
• Managed access requires a BetterFleet decision before start for supported chargers.
• Known active own-fleet identifiers are allowed in managed access.
• Unknown identifiers are denied in managed access.
• Denials are access-control outcomes and should not appear as charger faults by default.
• Unsupported chargers cannot be scheduled for fully managed access without a warning or block.
• A failed scheduled mode change creates an access-control problem state.
• Examples:
• Known own-fleet RFID during managed access: allow and record decision.
• Unknown RFID during managed access: deny and record access-denied decision.
• Unknown RFID during freevend: no BetterFleet access decision, unless existing charger behaviour reports one.
• Charger offline when schedule switches to managed access: expected mode changes, observed mode is unknown/out of sync.
• OCPP 2.0.1 charger authorises during first phase: unsupported for managed access unless the path is implemented.
• Counterexamples:
• A blocked identifier due to expired credential may need a different denial reason than unknown identifier.
• A charger rejecting ChangeConfiguration is a mode-change problem, not a denied vehicle attempt.
• A charger-side local-auth rejection may be observed after BetterFleet allowed the attempt.
• Exploratory Given/When/Then examples:
• Given a charger is in managed access and an active own-fleet identifier is presented, when the charger requests authorisation, then BetterFleet allows the start and records an allowed access decision.
• Given a charger is in managed access and an unknown identifier is presented, when the charger requests authorisation, then BetterFleet denies the start and records an access-denied decision separate from fault incidents.
• Given a charger is scheduled to enter managed access and is offline at the boundary, when the schedule is evaluated, then BetterFleet records expected mode as managed access and observed mode as not confirmed.
• Given a charger is OCPP 2.0.1 and its authorisation resolver still accepts all identifiers, when an operator tries to enable managed access, then BetterFleet shows the charger as unsupported or partially supported.
• Given two schedules overlap for one charger, when the operator saves the second schedule, then BetterFleet prevents the overlap or requires an explicit priority.
• Open behavior questions:
• Should denied access be visible in the same incident list, a separate access-events list, or charger detail timeline?
• Should freevend periods disable Core authorisation, switch charger config, or both?
• How should offline chargers catch up after missing several schedule boundaries?
• Are schedule windows inclusive at start and exclusive at end?
• How should skipped/repeated local times during daylight-saving transitions be handled?

DDD and Eventstorming Exploration

• Bounded context:
• Charger Access Control is the candidate bounded context for policy, schedule evaluation, expected mode, mode-change requests, and access decisions.
• Vehicle Access Identity may stay within existing vehicle management for own-fleet identifiers at first, with an explicit port for agreement identifiers later.
• Operations Visibility consumes access decisions and mode-change problems as read models.
• Ubiquitous language:
• Access mode: freevend, managed_access.
• Expected access mode: mode derived from schedule at a time.
• Observed access mode: mode confirmed or inferred from charger/config state.
• Access capability: support for remote freevend switching and pre-start authorisation.
• Access decision: allow/deny result for a managed-access attempt.
• Denial reason: unknown identifier, inactive identifier, unsupported charger path, stale agreement, charger-local rejection, authorisation timeout.
• Actors:
• Depot operator, operations user, support user, charger integration, schedule evaluator, vehicle identifier source, agreement identifier source.
• Commands:
• ConfigureChargerAccessSchedule
• EvaluateChargerAccessMode
• RequestChargerAccessModeChange
• ConfirmChargerAccessModeChange
• ClassifyVehicleIdentifier
• RecordAccessDecision
• PublishAccessDecisionForOperations
• Policies:
• Schedule policy decides expected access mode.
• Capability policy decides whether a charger can be fully supported.
• Authorisation policy maps identifier class to allow/deny.
• Visibility policy decides whether an event is access-denied, mode-change problem, or incident.
• Privacy policy decides whether raw, masked, or hashed identifiers may be stored and shown.
• Aggregates / entities:
• ChargerAccessPolicy: owns charger-level schedule references and current policy state.
• ChargerAccessSchedule: recurring access window.
• ChargerAccessCapability: capability record/read model per charger/protocol.
• AccessDecisionRecord: immutable decision/audit record.
• Existing Vehicle and VehicleIdentifierMap: likely own-fleet identifier source.
• Value objects:
• AccessMode
• AccessClass
• IdentifierType
• MaskedIdentifier
• ScheduleWindow
• ModeChangeStatus
• DenialReason
• Domain events:
• Conceptual product facts:
  • charger_access.schedule_configured
  • charger_access.expected_mode_changed
  • charger_access.mode_change_requested
  • charger_access.mode_change_confirmed
  • charger_access.mode_change_failed
  • charger_access.identifier_classified
  • charger_access.decision_recorded
• Implementation commitment is open. ADR 0023 is proposed, so the spec should avoid requiring a real event bus unless delivery needs it.
• Event timeline:
• Operator configures recurring schedule.
• Scheduler/evaluator derives expected mode at the boundary.
• Integration requests charger config change.
• Charger confirms, rejects, or misses the change.
• Charger asks for authorisation during managed access.
• Core classifies identifier and records decision.
• Operations view consumes access decision or mode-change problem.
• Invariants:
• A fully supported managed-access charger must ask BetterFleet for authorisation before start.
• Unknown identifiers are denied during managed access.
• Access decisions are immutable audit records.
• A denied access attempt is separate from a charger fault by default.
• Schedule evaluation uses timezone-aware storage and deterministic local-time interpretation.
• Account-level identifier uniqueness is preserved.
• Event dictionary:
• charger_access.decision_recorded: access attempt was allowed or denied; includes charger, account, timestamp, masked identifier, access class, decision, reason, policy source.
• charger_access.mode_change_failed: scheduled access mode could not be applied; includes charger, expected mode, attempted config path, failure reason, timestamp.
• charger_access.expected_mode_changed: expected mode changed due to schedule evaluation; includes charger, previous mode, next mode, schedule id, effective time.

UX and User Flow Exploration

• Current surfaces:
• Depot vehicle settings include an Identifiers accordion for MAC, RFID, PIN, and similar values.
• Mobile Ops charger detail shows charger status, connector status, remote start/stop, cable release, zone, circuit, model, and serial.
• Mobile Ops incidents list active incidents for the selected depot and links affected chargers.
• Charger advanced settings expose Authorise Transactions through backend metadata.
• Changed places:
• Charger settings or charger detail needs an access policy area.
• Operations views need a way to see access-denied decisions separate from faults.
• Vehicle settings may need clearer identifier type/lifecycle if identifier classification becomes customer-facing.
• Admin/interoperability tools may need capability discovery around freevend and authorisation keys.
• Breadboard:
• Charger access settings:
  • Capability state: fully supported / partially supported / unsupported.
  • Current expected mode and observed/confirmed mode.
  • Recurring schedule list.
  • Last mode-change attempt and result.
• Access decisions:
  • Charger detail timeline or table.
  • Columns: time, decision, reason, identifier type, masked identifier, matched vehicle/agreement when allowed, source policy.
• Operations summary:
  • Count of access-denied attempts.
  • Filter by charger, reason, and time range.
• Fat marker sketch notes:
• Keep access policy close to the charger rather than buried in raw advanced settings.
• Denials need operational language: "Access denied" rather than "incident" or "charger fault".
• Capability state needs to block setup when managed access cannot be enforced.
• States, errors, and degraded modes:
• Unsupported charger: cannot enable scheduled managed access.
• Partially supported charger: can show expected policy, but cannot apply freevend or pre-start authorisation safely.
• Offline charger at boundary: expected mode changes; observed mode is unconfirmed.
• Configuration rejected: mode-change problem with retry/manual action.
• Unknown identifier: access denied.
• Authorisation service timeout: open decision needed, fail closed during managed access is the safer policy but may affect driver experience.
• Help-doc impact:
• Operators need help text for freevend vs managed access, capability states, schedule windows, and denied attempts.
• Support docs need denial reason guidance and how to distinguish policy denial from charger fault.

Technical Surface Exploration

• Frontend surface:
• Existing React Query service patterns should carry any new charger access endpoints through src/services/.
• Existing vehicle identifier UI can remain the own-fleet source for a first slice.
• Mobile Ops surfaces are viable for first operations visibility but may not be the final desktop reporting surface.
• New forms should likely use react-hook-form and existing UI primitives.
• Backend/domain surface:
• Existing Core path:
  • /api/transaction/authorise accepts charge_point_id and id_tag.
  • transaction_auth_check loads charger and depot, checks VehicleIdentifierMap, then applies authorise_transactions.
  • Unknown identifiers publish an unknown_vehicle_identifier error event.
• Existing Connect path:
  • OCPP 1.6 Authorize formats the id tag and calls Core.
  • OCPP 2.0.1 Authorize currently returns accepted.
• Candidate domain change:
  • Extract access decision recording before incident publishing.
  • Treat current incident as one possible downstream projection, if still needed.
  • Add ports for own-fleet identifier lookup and agreement identifier lookup.
• Data and integration surface:
• vehicle_identifier_mapping has a unique account/id tag constraint.
• Existing identifier records do not appear to carry identifier type, status, source, or agreement ownership.
• Freevend keys are visible in OCPP 1.6 interop tooling, but delivery needs charger-model validation.
• OCPP configuration apply/response paths exist for v1.6 ChangeConfiguration and v2.0.1 SetVariables.
• Observability / support:
• Current unknown-identifier event severity is error.
• Current detail includes raw idTag.
• Access decisions need auditability, retry/idempotency handling, and masked display.
• Mode-change failures need operator-visible status and logs.
• Security / privacy:
• Raw identifiers should be treated as sensitive until a privacy decision says otherwise.
• Support views need enough information to resolve a denied attempt without broad raw identifier exposure.
• Authorisation endpoints are m2m/integration surfaces and should keep existing authentication posture.
• Release / rollout:
• Customer exposure should be behind a staged Manage feature flag.
• Public/internal release notes should avoid raw flag names.
• Help docs should be updated when operators can configure schedules or see access-denied outcomes.

Perspective Review

Perspective	What we found	Evidence	Spec impact
User/customer value	The challenge value is clear: scheduled open/restricted access and clear denials.	challenge.md	Preserve the main outcome, but split delivery.
Product/business	Agreement vehicle access is strategically important but lacks a visible source system.	No agreement identifier source found locally.	Treat agreement identifiers as dependency or later slice.
UX/user flow	Existing charger, incident, and vehicle identifier surfaces can host first experiences.	Mobile Ops and Depot Vehicles files reviewed.	Revised spec should pick first visibility and configuration surfaces.
Business logic/domain	Existing authorise_transactions and identifier lookup can support an own-fleet managed-access slice.	transaction_auth.py, service_layer.py, charge_point_aggregate.py	Map raw settings to product access modes.
Frontend	Vehicle identifiers exist, but identifier type/lifecycle is thin.	VehicleSettingsSBC.tsx, vehicle.ts	Spec should avoid promising rich classification until data model supports it.
Backend/data/integration	OCPP 1.6 supports authorisation callout; OCPP 2.0.1 currently accepts all.	Connect authorise resolvers.	First supported path should be OCPP 1.6 unless 2.0.1 is implemented.
Operations/release/support	Unknown identifier is currently an error incident with raw id tag.	incidents/types.py, transaction_auth.py	Need access-decision record and privacy policy before broad visibility.
Delivery/story readiness	First slices are visible, but blocking choices remain.	Review findings plus code evidence.	Dossier is not ready for spec writer until owner answers first-path and agreement-source questions.

Scope Pressure and Ambiguities

• Blocking questions:
• Which charger model/protocol is the first supported target?
• Can that target reliably switch freevend remotely, and through which key/variable?
• Is OCPP 1.6 the first managed-access path?
• What is the agreement identifier source of truth?
• Should first delivery include agreement vehicles, or only preserve a contract for them?
• Should access-denied attempts stop being incidents immediately, or should incidents remain as a temporary projection while a new access-decision view is built?
• What is the privacy rule for raw identifiers in records, logs, and UI?
• What recurrence shape is required for the first schedule UI?
• Non-blocking assumptions:
• Own-fleet identifiers can start from existing VehicleIdentifierMap.
• Account-level uniqueness for identifiers should remain.
• Manual overrides can be deferred if schedule boundary failures have clear visibility.
• OCPP 2.0.1 can be marked unsupported for managed access until its authorisation resolver calls Core.
• Risks:
• Reusing incidents for denials undermines the challenge outcome.
• Shipping schedule UI before charger capability is proven could create false confidence.
• Storing raw identifiers in access decisions may create avoidable privacy exposure.
• A broad first story could become integration-heavy across Connect, Core, Manage, docs, and support.
• Treating agreement vehicles as required in the first slice could block progress on an unavailable upstream data source.
• Out-of-scope candidates:
• Billing and settlement.
• Driver account management.
• Broad marketplace agreement flows.
• OCPP 2.0.1 managed access unless explicitly chosen as first path.
• Connector-level, zone-level, depot-level inheritance.
• Manual override UI, unless needed for safe recovery.

Synthesis for Specification Writer

• Decisions to carry forward:
• Keep product modes as freevend and managed_access.
• Separate expected access mode from observed/confirmed charger mode.
• Treat capability as a first-class prerequisite.
• Use existing own-fleet vehicle identifiers for the first feasible managed-access slice.
• Record access decisions separately from charger faults and incidents.
• Keep agreement identifier integration as a named dependency until its source is confirmed.
• Keep event names conceptual unless the technical design chooses event infrastructure.
• Material to compress:
• Current authorisation flow evidence.
• Capability-state model.
• First-slice recommendation.
• Blocking questions and dependencies.
• Material to omit from the concise spec:
• Detailed code-path inventory.
• Full event dictionary unless it becomes a real implementation commitment.
• Exploratory BDD examples that are not yet story-ready.
• Recommended build items:
• Charger access capability model/read endpoint.
• Access decision record.
• Own-fleet identifier classifier port using existing identifiers.
• OCPP 1.6 managed-access authorisation hardening.
• Access-denied operations visibility.
• Recurring schedule model and evaluator.
• Mode-change apply and confirmation path for one supported charger family.
• Suggested requirements:
• The system shall expose whether each charger supports remote freevend switching and pre-start authorisation.
• The system shall record managed-access allow/deny decisions with masked identifier context.
• The system shall deny unknown identifiers during managed access for supported chargers.
• The system shall avoid creating charger fault incidents for expected policy denials by default.
• The system shall show expected and observed access mode when scheduled changes cannot be confirmed.
• The system shall use depot-local schedule presentation and UTC internal storage.
• Suggested review perspectives:
• Charger integration/OCPP.
• Backend domain/data.
• Manage UX.
• Operations/support.
• Security/privacy.
• Release/help docs.

Recommended Spec Shape

• Spec type: concise product/domain specification with an explicit first supported slice and capability matrix.
• Sections to include:
• Intent and scope.
• Current baseline.
• Capability states.
• Conceptual model.
• First supported protocol/charger path.
• Access decision and identifier privacy.
• Schedule semantics.
• Operations visibility.
• Dependencies and open questions.
• Delivery slices.
• Sections to omit or keep light:
• Detailed event bus mechanics.
• Billing/settlement.
• Agreement lifecycle details beyond the identifier-source contract.
• Broad future inheritance models.
• Low-fidelity UX artifact needed:
• Yes. A simple charger access settings breadboard and access-denied timeline/table should be added before final review.
• Diagram or eventstorming needed:
• Yes. Keep a small flow diagram for schedule evaluation and authorisation decision.
• Required review perspectives:
• Product owner.
• Charger/OCPP technical owner.
• Manage frontend owner.
• Core/domain owner.
• Support/operations representative.
• Security/privacy reviewer for identifiers.

Handoff

• Ready for specification-writer: no
• If no, next step:
• Answer the first-path and identifier-source questions below, then either continue exploration or compress the settled decisions into a revised specification.
• Suggested target spec path:
• Keep local working artifacts in docs/work/active/enable-scheduled-managed-charger-access/ for now.
• Create or select a Linear Project before treating the final concise specification as canonical.

Questions For Owner Input

1. Which charger/protocol path should anchor the first supported slice: OCPP 1.6 with the existing Core authorisation path, OCPP 2.0.1, or a named charger family?
2. Should agreement vehicles be part of the first delivery, or should the first delivery prove own-fleet managed access and leave agreement identifiers as a dependency?
3. Where should access-denied outcomes appear first: charger detail, a separate operations access-events view, the incident list with different typing, or customer-facing reports?