The companion to /embedded/integrate/ (5-min dev walkthrough). This page is written for the IT operations, security engineering, vendor risk, and DPO seats at a SaaS customer who is being asked to approve and operate Kinetic Gain Embedded inside their stack. The format is what those teams will actually want from you: pre-approval checklist, change-management ticket template, phased rollout plan, day-2 operations expectations, audit cadence, and a documented off-boarding plan. Lift wholesale into your ticketing system; everything below is intended as a starting artifact, not a sales surface.
Before the change-management ticket goes in, gather this. Most of it the vendor publishes; the rest you decide. Each line maps to a specific buyer question.
Lives at /embedded/threat-model/. Reviewer notes which trust boundaries the SDK assumes, which it explicitly does not, and what failure modes apply. Time: ~15 min.
npm view kinetic-gain-embedded should show an npm provenance badge tying the published bundle to a specific GitHub Actions build. If not, the supply chain isn't what the vendor claims it is. npmjs.com/package/kinetic-gain-embedded.
SBOM is attached to each GitHub release as a CycloneDX JSON. Diff against your existing approved-dependency list. Block any package you don't recognize; the SDK ships zero runtime deps so this list should be effectively empty.
SDK is Apache-2.0 (permissive, patent grant). Hosted tier terms are separate; that's where indemnification + DPA + SCC language lives. Get both reviewed; they cover different scopes.
What data does the SDK see? The Decision Card body, the customer record at tokenization time, and the audit event metadata. Confirm each is classified under your existing register (Public / Internal / Confidential / Restricted) and that the SDK's handling matches your policy for that class.
If you're using ed25519 signing on audit events, you (the customer-of-the-embedder) decide where the public key lives. Recommended: your own .well-known/ at your apex domain. The embedder doesn't need your private key — only the public key for verification.
You sign the Decision Card once. It locks the policy bundle the SDK enforces at runtime. Save the canonical JSON in your evidence locker. Reference spec.
Three options: (a) self-hosted endpoint, (b) embedder's hosted tier, (c) drop-in to your existing SIEM (Splunk, Sentinel, Datadog). For regulated workloads pick (a) or (c); (b) is fine for non-regulated.
The ticket your CAB needs. Each field aligns to a question they will ask. Paste, fill in your specifics.
Title: Approve kinetic-gain-embedded SDK v<X.Y.Z> rollout to <product>
Risk class: Low / Medium / High (default: Medium, drop to Low after one quarter clean)
Type: Third-party dependency · AI governance instrumentation
Requestor: <eng lead>
Owner: <eng lead> (build) · <security eng> (verify) · <DPO> (sign-off)
WHAT
Drop in kinetic-gain-embedded SDK at version <X.Y.Z> into <service>.
Emits hash-chained, ed25519-signed audit events on AI-touching code paths.
WHY
Buyer-side AI governance compliance. Audit-stream creates the
verifiable record our customers' compliance teams ask for.
DATA SCOPE
- Reads: Decision Card (we control), customer record at tokenization point
- Writes: Audit events to <destination — SIEM endpoint URL or hosted tier>
- Retains: Audit events for <Y days> per data-retention schedule
- Does NOT: Send raw customer records off-prem; the SDK tokenizes
before any cross-boundary call
DEPENDENCIES
Runtime deps: 0
Build deps: see SBOM attached
Network egress: <list endpoints + ports — or "none, SDK is offline">
VERIFICATION CHECKLIST (pre-prod gate)
[ ] SBOM diffed vs approved-dependency register
[ ] npm provenance badge verified at install time
[ ] Threat model read end-to-end by reviewer
[ ] Audit-event roundtrip tested in staging
[ ] ed25519 signature verification confirmed end-to-end
[ ] Decision Card canonical JSON archived in evidence locker
[ ] Rollback procedure tested (see Section 6)
[ ] On-call playbook updated (see Section 4)
ROLLOUT
Phase 1 — Internal staging (1 week)
Phase 2 — 5% production (2 weeks)
Phase 3 — General availability after both phases clean
ROLLBACK
npm install kinetic-gain-embedded@<previous>
redeploy <service>; audit-stream pause is graceful
(the embedder side does NOT block on audit emission)
CONTACTS
Vendor: security@kineticgain.com (RFC 9116 security.txt verified)
Internal owner: <eng lead>
Escalation: <DPO>Standard SaaS-vendor rollout shape: stage → canary → GA. Each phase has explicit exit criteria; don't progress until every criterion is met.
Drop the SDK into one non-production service. Wire a synthetic Decision Card. Verify every audit event roundtrips through your SIEM with intact hash chain + valid ed25519 signature.
Enable the SDK for 5% of production traffic on the same service. Real Decision Card from the buyer. Real records. Production audit-stream destination. Hold here for two full weeks of business-hours operations.
100% production. Move into normal day-2 operations (Section 4). The SDK is now part of your supported stack. Quarterly review begins (Section 5).
The SDK does not require dedicated on-call. It is a synchronous library — when your service is healthy, the SDK is healthy. The only operational surface is the audit-stream destination: if that endpoint stops responding, the SDK degrades gracefully (events buffer in-process up to a configurable cap, then drop with a warning log).
/.well-known/security.txt for current contact + signing-policy page.What to put on the operations calendar. Treat the SDK as a third-party dependency with audit obligations.
| Cadence | What | Why |
|---|---|---|
| Weekly | SIEM dashboard review: event volume, hash-chain breaks (should be 0), signature failures (should be 0) | Catch silent failures within 7 days, not 90. |
| Monthly | SDK version reconciliation: services on stale SDK versions surface as a backlog ticket | Prevent CVE exposure window from compounding silently. |
| Quarterly | Decision Card review: re-confirm the buyer-side policy bundle is still the policy you want enforced. Re-sign if anything material changed. | Decision Cards are immutable per version; if your policy changed, you need a new version + re-signing. |
| Quarterly | Vendor /.well-known/ freshness check: pull kineticgain.com/.well-known/aeo.json + 10 sibling docs, verify ed25519 signatures still validate |
If the embedder rotated keys or the signatures expired, your signed audit events depend on a chain you no longer trust. |
| Annually | Threat model re-read: assumptions may have changed (new attack classes, new regulatory frameworks). Update accepted-risks list. | Threat models age. Yours and the embedder's. |
| Annually | Access review on the audit-stream destination: who can read the audit log, who can write, who can delete | An audit log nobody but the right people can touch is worth more than a perfect signature. |
| Annually | Off-boarding drill (dry-run): confirm the off-boarding plan in Section 6 still executes cleanly against current architecture | Untested rollback plans are a fiction your incident response can't rely on. |
How to safely remove KGE from your stack. Treat as a one-quarter operation, not a one-day operation — the audit-stream history needs to remain available for buyer-side compliance even after you stop emitting new events.
npm uninstall kinetic-gain-embedded, redeploy. The audit log is now read-only history. Update your data-retention schedule + vendor register.Everything below is intended to be read end-to-end before approval, then referenced as needed during operations.