@lssm-tech/lib.customer-support-runtime
Provider-neutral SupportOS runtime with an event-sourced in-memory conformance authority, optimistic concurrency, workspace isolation, keyset pagination, deterministic SLA helpers, graduated-autonomy enforcement, and reference-only ecosystem hand-offs.
The platform-authority, platform-authority-bindings and
platform-authority-binding-registry entries own the existing provider-neutral authority composition, required operation/binding checks and legacy adapter. The supported contracts-spec/customer-support exports forward to these same objects. Composition preserves supplied authority ports and does not authorize live effects or provide a concrete persistence adapter.
The relation authority executes merge, split, and link mutations under a per-workspace serialization fence. It validates both case revisions, advances both event streams atomically, and returns the original immutable result for exact idempotent replays.
The skills-routing evaluator is pure and replayable. It filters bounded opaque candidate projections by exclusion, availability, capacity, and required skills, then applies explicit preferred-team, load, oldest-assignment, and stable-reference ordering. Skill fallback is opt-in and visible in the trace. Assignment remains a separate governed effect.
The cryptographic lifecycle facade validates provider-neutral KMS and secret adapters before their evidence reaches a SupportOS authority. It enforces exact purpose/algorithm descriptors, tenant/workspace/data-class context binding, versioned envelope evidence, fenced rotation results, bounded lookup hashes, and scope-bound secret references. Plaintext data keys are always returned as destroyable values and are zeroized even when a provider cleanup hook fails. This facade is not a KMS implementation: managed providers, durable rotation ledgers, re-encryption workers, and production rotation drills remain host work.
CommunicationOS remains authoritative for message bodies and delivery. Forms remains authoritative for answers and verification. Personalization can change presentation only. Consequential CompanyOS operations require typed operation references and Connect evidence.
The OPA handoff authority is a provider-neutral local conformance runtime for public profile and booking journeys. It verifies the current case revision, mints a consent receipt, resolves only through a host-supplied OPA destination port, accepts public HTTPS URLs, isolates tenant/workspace state, and preserves exact idempotent replay. Returned bookings require an opaque booking reference; no owner scope, public bearer token, visitor answer, calendar record, or provider payload is persisted in the SupportOS projection.
The CSAT leaves preserve the canonical response and survey authority ports, complete server authority scope, and synchronous privacy-safe input digest. Forms imports these narrow leaves directly. The digest retains the existing Core canonical serializer and synchronous SHA-256 implementation; grant metadata is excluded before hashing. Other runtime families still have legacy dependencies.
The complete contracts required by the runtime are exposed through narrow contracts/* leaves: case models, authority ports and errors, lifecycle and presence contracts, assignment and relation rules, provider projections, OPA handoffs, skills routing, and cryptographic lifecycle contracts and supplied-evidence validation. These leaves, authority-scope and the CSAT leaves now forward to their canonical owner @lssm-tech/lib.customer-support-spec, as do the legacy ContractSpec exports, so each export keeps one identity. The runtime imports no Legacy source and retains the complete original policy and security checks.
Support resolution workflow (support-resolution-v1)
SupportResolutionWorkflow composes the provider-neutral conversation reader, action, approval, engineering-work and resolution-store ports from
@lssm-tech/lib.customer-support-spec. recover records customer issue parts from the provider conversation (the provider stays authoritative); propose
requires citations to observed parts, knowledge or the linked engineering work and invalidates earlier approvals; approve needs a non-agent principal with
support.resolution.approve and an approval bound to the exact action digest whose verified signer is a human, matches approvedByRef and is neither the proposer nor the responder (supportApproverIdentityHolds compares principal refs; a host that records a provider admin id such as an Intercom admin_id as
responderRef binds responderPrincipals, for example
staticSupportResponderPrincipals, and then an unmapped responder is refused and the mapped principal may never approve);
dispatch refuses agent and unidentified principals and sends customer-visible replies only when approved, re-reading the signer through
recordedSupportResolutionApproval(projection, identity) and the responder mapping before the effect (a failed identity or mapping lookup is
DEPENDENCY_DEGRADED; an unapproved internal note needs a Connect admission); reconcile resolves response-uncertain by read-back only, and
confirmResponseAbsent lets a human confirm an absent response. recordOutcome proves the agreed criterion (customer confirmation, a fixed work item plus a later cited notification, or an answer without follow-up) and a new customer message reopens the workflow. InMemorySupportResolutionStore
is a reference store; production hosts bind a durable implementation.
