feat(demo): update document-rag demo and seperated it from the previous branch

Author: ishnbl

demo/document-rag/documents/api-integration-guide.md

@@ -0,0 +1,26 @@
+# Vortex Cloud API Integration Guide
+
+**API version:** v2  
+**Updated:** 2026-05-18
+
+The Vortex Cloud API lets customers read site telemetry, acknowledge alarms, and export reports. API access is available on Growth and Enterprise plans.
+
+## Authentication
+
+Use an organization-scoped service account with a short-lived OAuth token. Tokens expire after one hour. Service accounts receive only the scopes explicitly assigned to them; use `telemetry:read`, `alarms:write`, and `reports:read` rather than a broad administrative scope.
+
+## Key endpoints
+
+`GET /v2/sites/{site_id}/telemetry?from=&to=` returns normalized readings. The maximum query window is 31 days.
+
+`GET /v2/alarms` accepts filters for status, severity, site, and tag. Alarm timestamps are in UTC.
+
+`POST /v2/alarms/{alarm_id}/acknowledgements` records the named operator, timestamp, and optional note. It does not resolve the alarm; resolution requires the `alarms:resolve` scope.
+
+`POST /v2/exports` creates an asynchronous CSV or Parquet export. Exports are retained for 24 hours and are listed in the audit log.
+
+## Rate limits and backfill
+
+The default limit is 120 requests per minute per service account. During an Aster connectivity recovery, telemetry can arrive up to 72 hours late; clients should order records by `observed_at`, not API receipt time.
+
+Never embed service-account secrets in Aster configuration files or source repositories.

demo/document-rag/documents/chunking-config.csv

@@ -0,0 +1,22 @@
+# Vortex Lab: Company Overview
+
+**Updated:** 2026-06-12  
+**Owner:** Maya Chen, Chief Executive Officer
+
+Vortex Lab builds software for teams operating distributed energy equipment: solar farms, battery sites, and microgrids. Its platform combines rugged edge gateways with a cloud control plane that turns noisy device readings into actionable operating signals.
+
+## Products
+
+- **Aster Edge** collects telemetry from site controllers, normalizes common industrial protocols, and can keep operating while disconnected.
+- **Vortex Cloud** stores, visualizes, and routes telemetry, alarms, maintenance notes, and reports.
+- **Pulse** is the anomaly-detection service used to prioritize alerts.
+
+## Customers and operating model
+
+Our customers are asset owners and service providers with 20 to 2,000 sites. They typically use Vortex during daily operations, incident response, and monthly performance reviews. Customer Success owns adoption; Reliability Engineering owns the shared cloud platform; Support owns first response for production incidents.
+
+Vortex Lab’s stated operating principle is: **an alert should lead to a clear next action, not merely more data**.
+
+## Current priorities
+
+For the second half of 2026, the company is focused on reducing false-positive alerts, expanding offline workflows in Aster Edge, and improving export controls for enterprise customers. The public product roadmap is in `product-roadmap-2026-h2.md`.

demo/document-rag/documents/cloudflare-models.txt

@@ -0,0 +1,20 @@
+# Employee Onboarding: Operations and Engineering
+
+**Updated:** 2026-06-08
+
+Welcome to Vortex Lab. During your first week, complete security training, request the least-privilege role for your work, and join your team’s service rotation shadow session.
+
+## Required setup
+
+1. Enroll a hardware security key in SSO.
+2. Activate the password manager and store no customer credentials elsewhere.
+3. Read the Security and Access Policy and acknowledge the acceptable-use statement.
+4. Request staging access through Access Hub; do not request production access until your manager identifies a business need.
+
+## Working with customer information
+
+Use a customer’s organization ID, not its name, in internal engineering logs whenever practical. Do not download raw telemetry to personal machines. Support attachments must be placed in the case workspace, which applies access controls and retention rules.
+
+## Escalation
+
+For a production issue, page the on-call reliability engineer. For a suspected security event, follow the one-hour reporting requirement in `security-and-access-policy.md`.

demo/document-rag/documents/company-overview.md

@@ -0,0 +1,18 @@
+# ADR-042: Keep a 10-Minute Alert Watermark
+
+**Date:** 2026-05-28  
+**Status:** Accepted
+
+## Context
+
+Pulse must handle delayed telemetry from Aster Edge without causing duplicate or misleading pages. A May incident demonstrated that a globally expanded 60-minute watermark made operational alerts unacceptably late for battery customers.
+
+## Decision
+
+The default alert watermark remains 10 minutes. Any exception longer than 15 minutes must be organization-scoped, approved by Reliability Engineering, have an expiry date, and be covered by a replay test using delayed events.
+
+Events received after the watermark are marked as backfill. They update historical charts and reports but do not reopen a resolved alarm automatically. Operators can manually review a backfill event from the alarm timeline.
+
+## Consequences
+
+Some intermittently connected sites may continue to create duplicate candidate alerts, which Pulse deduplicates using rule and event identity. This is preferable to silently delaying high-severity alerts across unrelated customers.

demo/document-rag/documents/employee-onboarding.md

@@ -0,0 +1,19 @@
+# Incident Report: Northstar Alert Delay
+
+**Date:** 2026-05-14  
+**Severity:** SEV-2  
+**Status:** Closed
+
+## Summary
+
+Northstar Energy received delayed high-temperature alerts for three battery sites between 09:12 and 10:03 UTC. No equipment damage occurred. Operators identified the condition through their local SCADA system and placed the affected units in a safe operating mode.
+
+## Cause
+
+On May 12, an alert-processing configuration change increased Pulse’s late-event watermark from 10 to 60 minutes for all organizations. The change was intended to reduce duplicate pages caused by one intermittent site. Aster Edge gateways at Northstar backfilled valid events after brief cellular outages; Pulse withheld their alert evaluation until the expanded watermark elapsed.
+
+## Resolution and follow-up
+
+The watermark was restored to 10 minutes at 10:03 UTC. We added organization-scoped configuration validation, a test fixture for delayed Aster events, and a dashboard showing alert-evaluation lag. The previous customer-specific workaround was removed.
+
+Northstar received a written incident summary, a 30-day alerting credit, and weekly progress updates until the follow-up items were complete. See `q2-customer-success-notes.md` for the commercial commitments.

demo/document-rag/documents/engineering-decision-record-042.md

@@ -0,0 +1,19 @@
+# Monthly Operations Report — June 2026
+
+**Prepared:** 2026-07-05
+
+## Reliability snapshot
+
+Vortex Cloud availability was 99.96% in June. Median telemetry ingestion latency was 4.2 seconds for connected sites. 94.1% of delayed Aster uploads completed within 12 minutes after connectivity was restored.
+
+## Alert quality
+
+High-severity alert median evaluation time was 7.8 minutes, down from 18.4 minutes in May. The improvement followed the restoration of the 10-minute Pulse watermark and the addition of evaluation-lag monitoring. The Northstar pilot reported two actionable backfill labels and no delayed high-temperature pages during the month.
+
+## Open work
+
+Engineering is completing API support for `is_backfill`; this remains targeted for July. Customer Success is validating the weekly alert-quality report before offering it to other battery customers.
+
+## Retention reminder
+
+Raw telemetry retention follows each customer’s plan or contract. Growth includes 90 days under the April 2026 plan update; data exports are available for 24 hours after creation.

demo/document-rag/documents/incident-2026-05-northstar.md

@@ -0,0 +1,21 @@
+# Platform Architecture
+
+**Updated:** 2026-06-10  
+**Audience:** Engineering and Security
+
+Vortex Cloud separates ingestion, operational storage, alert evaluation, and customer-facing applications.
+
+1. **Ingress** validates device identity, schema, and message signatures.
+2. **Stream processing** enriches events with site metadata and writes immutable raw telemetry.
+3. **Pulse** evaluates anomaly models and deterministic alert rules.
+4. **Operations API** serves the web application, reports, and customer integrations.
+
+Raw telemetry is encrypted at rest and logically partitioned by organization ID. The web application uses the Operations API; it does not directly query the telemetry store. Customer data is replicated within the selected hosting region for durability.
+
+## Resilience
+
+Ingress accepts delayed events from Aster Edge and deduplicates them using gateway ID, sequence number, and observed timestamp. Pulse uses a 10-minute watermark for normal alert evaluation; events older than the watermark are marked as backfill and may update reports, but do not automatically reopen a resolved incident.
+
+## Known trade-off
+
+The watermark avoids duplicate pages during connectivity recovery, but it can delay alert classification for intermittently connected sites. The Northstar incident in May 2026 exposed a configuration error in this boundary; details are in `incident-2026-05-northstar.md`.