Red Line engineering package
Status: local reference model and implementation blueprint, 12 November 2026. This is not a deployed authenticated service or security certification. The existing private Site remains a concept walkthrough. No real contacts, credentials, calls, grants or costs are involved.
Run: python3 -m unittest discover -s engineering/tests -v
35 local SQLite fixture tests pass. These demonstrate selected domain invariants: tenant-scoped queries, role checks, ordinary escalation versus activation, takeover lease, original deadline preservation, contact idempotency, acknowledgment versus approval, bounded approval scope, safe expiry and queued-attempt cancellation. They do not establish production concurrency, browser security, provider delivery, durable scheduling, billing or legal compliance.
Recommended first production slice
A single owner, two agents, one written channel, one non-destructive escalation. Verify wake, receive, reply, explicit decision, cancellation and audit evidence before adding a call/SMS channel or multiple owners. Do not require a new authorization for each already-authorized low-risk action. Reversibility is a design technique, not a grant of authority.
System boundaries
1. Public product site explains Red Line. No private incident content in public HTML, metadata or analytics.
2. Owner application authenticates people, provisions portfolios, configures decision policy, AOP and backup, verifies contact endpoints, and displays incidents.
3. Policy/state service authorizes every operation by principal + portfolio membership + role + resource. Maintains incident version, original deadline, current coordinator lease and immutable event history.
4. Scheduler/outbox persists due work, atomically claims it, rechecks current incident state and route authorization immediately before send, and deduplicates provider calls using a unique attempt key.
5. Contact adapters email, SMS, voice or existing meeting relay. Each has a distinct verified capability and consent record. A link requiring a human to press Call is not an unattended outgoing call.
6. Agent adapter/MCP accepts signed, bounded agent requests. It cannot grant itself membership, decision authority, contact permission or unlimited spend. DiOS is one client, not the product's only integration.
7. Audit and observability records event time, actor, state version, delivery receipt, owner acknowledgment and decision separately. Operational alarms report scheduler and channel failure.
Multi-owner identity and isolation
For a Sites implementation, use its hosted authentication integration. Server receives the documented authenticated stable Site user ID; never take it from request JSON. Sites identity is not portfolio membership. In production, only trust the header behind the Sites dispatch boundary; prevent direct access to an origin accepting spoofed identity headers. No hosted authentication route has been built or qualified in this package.
Portfolio membership is explicit. One user may own several portfolios; no global owner role implies access to every tenant. Every table uses tenant_id, every incident foreign key includes tenant_id, every read/update/delete includes it, and every join retains it. Do not trust a URL tenant ID without server-side membership authorization. Contacts, audit, exports, search, file paths, websocket subscriptions and worker queues require the same boundary. Use nondisclosing errors for nonexistent/unauthorized resources. Emails are contact/display values, never identity keys. Do not auto-link accounts on matching email alone.
Suggested roles: owner, primary AOP, backup AOP, agent, read-only auditor. Only owner can record reserved owner decisions or change policy/contacts/membership. AOP coordinates; backup takes over after a configured expiry or explicit owner assignment; agents submit blockers and contact opportunities. Auditor access is a deliberate grant, not default. Member removal revokes sessions/grants and scheduled access promptly.
Data model
- portfolios: ID, owner principal, name, policy version, timezone, status.
- memberships: portfolio ID, principal ID, role, grant version, revoked_at.
- agents: portfolio ID, stable identity, adapter identity, permitted scopes, availability.
- policies: thresholds, decision classes, permitted reversible actions, contact limits, fallback order, cost caps, quiet-hours exceptions, expiry.
- contact_routes: portfolio ID, owner recipient reference, channel, verified_at, consent scope, configuration reference. Secrets are separate encrypted server runtime values.
- incidents: portfolio ID, incident ID, source agent, question, impact/deadline, state, policy snapshot, activation time, target time, coordinator, lease/fencing token, version.
- contact_opportunities: incident ID, reporting agent, expected contact time, confidence, capabilities, expiry. A scheduled meeting is an opportunity, not proof of delivery.
- attempts: incident ID, unique idempotency key, provider reference, queued/due/sent/delivered/failed/cancelled, receipt times. Do not place raw sensitive content in logs.
- decisions: incident ID, authenticated owner, allowed/declined scope, constraints, expiry, source evidence, version. A read receipt is never a decision.
- audit_events: portfolio/incident, monotonic sequence, timestamp, actor, event payload and prior digest. Hash chains detect certain changes but do not stop a privileged database operator from rewriting the chain; signed external checkpoints or immutable storage are a later protection.
Proposed API contract
All mutation endpoints require authenticated principal, CSRF/origin protection for browser sessions, schema limits, rate limit, idempotency key where appropriate and an expected incident/policy version.
POST /v1/portfolios/:id/incidents: member creates ordinary escalation.
POST /v1/portfolios/:id/incidents/:incident/activate: policy-authorized AOP activates once.
POST .../opportunities: authorized agent reports owner-contact evidence.
POST .../lease/renew and .../lease/takeover: primary/backup with fencing and atomic conditional update.
POST .../attempts: current AOP queues an allowed route; server resolves recipient and authorization, never trusts caller-provided allowlists.
POST .../acknowledgments: records receipt only.
POST .../decisions: authenticated owner records exact scope; no implicit approval from timeout.
POST .../deescalate: current coordinator confirms blocker cleared, cancels unsent work.
GET .../events: tenant-authorized read, redacted and paginated.
Local Principal and authorized_routes arguments are test fixtures, not authentication or authorization adapters. Never expose those arguments directly as client-controlled JSON. The test core has no HTTP endpoint, no secrets and no connector.
State and concurrency requirements
ESCALATED -> ACTIVE -> APPROVED | DECLINED | DEESCALATED | TARGET_MISSED.
Create and activate are different operations. Activation sets the immutable 60-minute target. Backup takeover never resets it. Repeated activation must not extend the target. An explicit later owner decision needs a new/versioned action after target miss, not silent resumption of old work.
Use atomic compare-and-swap and transaction boundaries for all state changes. A lease has a monotonically increasing fencing token; outbox workers must reject a stale token even if the old AOP resumes. Start the clock from trusted server time, not client time. On owner decision/de-escalation, cancel queued attempts atomically. A send already in flight may still arrive: record that race and do not claim it can always be recalled. Before retrying uncertain delivery, consult the provider receipt; use provider idempotency where available. At-least-once scheduling plus idempotent effects is the target, not a blanket exactly-once promise.
The SQLite reference is deliberately local and single-process. Its selected conditional-update tests do not prove multi-worker isolation. Before deployment, add real concurrent datastore tests (simultaneous activation, takeover, decision, cancellation/send race) and crash recovery tests. D1/Worker ports require documented transaction/batch semantics and a durable scheduler or equivalent, not browser timers. No scheduled execution is installed by this package.
Suggested 5–60 minute play
This is a configurable default proposal, not a mandatory wait sequence. Resolve immediately when possible; a nearer external deadline compresses the plan.
0–5: record decision and impact; qualify threshold; activate; notify team; collect all expected owner contact within the hour; confirm primary/backup availability; choose earliest credible route. Start an already-authorized written route immediately if appropriate.
5: first status checkpoint. Have we reached the owner? Is the route real and authorized? If no working route exists, expose that blocker now, not at minute 60.
5–10: assign execution to capable agent, send one concise decision request, record receipts; use a 10-minute scheduled callback if available. Avoid duplicate noise.
10–20: check acknowledgment separately from decision; use next approved channel if the first fails or is not acknowledged within its configured window. Continue independent work.
20–30: refresh team opportunities, use the scheduled meeting if it remains the best route, reassess time remaining and consequence of waiting.
30–45: backup AOP monitors coordinator health; transfer atomically if unavailable; preserve the original timeline. AOP can always hand off sooner if needed.
45–55: make the final authorized contact attempts, clearly state decision deadline and safe fallback. Do not invent another recipient or new authority.
55–60: check outstanding delivery/decision state, cancel obsolete duplicates, prepare the safe-hold outcome.
60: if no authorized decision, keep only the blocked action on hold, record missed target and impact, notify through allowed channels, preserve evidence. No automatic yes, spending, expanded scope or automatic transfer of ownership.
The minutes are checkpoints, not proof of real-time delivery. An urgent five-minute problem must not wait an hour.
Onboarding path
1. Sign in as an owner. Create a portfolio, accept clearly presented terms and choose timezone.
2. Add named primary AOP and backup; verify identity/capability and restrict grants to this portfolio.
3. Define one-way decisions, permitted reversible scope, urgency thresholds and maximum risk/cost. Avoid vague 'do anything' grants.
4. Add contact endpoints; verify possession and record channel consent. Separate owner contacts from emergency third parties.
5. Pick channel order, quiet hours, exceptions, per-incident attempt cap and spend limit; show actual provider costs before enabling paid routes.
6. Configure safe fallback when no owner decision arrives. Incapacity/succession is not inferred from silence.
7. Run a harmless dry run: submission -> activation -> team report -> route -> acknowledgment -> explicit decision -> cancellation -> audit.
8. Review proof and activate only qualified routes. A channel's setup status and last live verification time remain visible.
Threat model and release gates
Threats: cross-tenant object access, spoofed agent identity, replayed owner approval, compromised contact endpoint, malicious task text, duplicate sends, stale AOP, clock manipulation, webhook forgery, credential leakage and denial-of-service.
Mitigations: scoped identity/membership, immutable policy snapshot, explicit scope/expiry, CSRF and same-origin protections, request and webhook signatures, nonce/idempotency, rate limits, server clock, durable fencing, secret isolation and strict connector allowlists. Treat task text, inbound replies and web content as data, not instruction authority.
Required tests: all CRUD and exports across two tenants, removed membership, missing identity, forged headers outside trusted ingress, stale decision versions, lease split-brain, no approval on delivery/ack/timeout, scheduler restart, cancellation race, signed/unsigned webhook, repeated click/retry, mobile layout/accessibility, real channel recipient verification, outage/cost cap behavior.
Deployment path
Keep the current static preview unchanged while building a separate authenticated branch. Prefer a bounded owner-private pilot first. A Sites Worker with platform identity + D1 can host the owner app, but the documented Sites storage and identity guides do not alone qualify durable scheduler/contact-provider behavior. Confirm the supported scheduling design and costs. A separate existing Railway service is an alternative if it fits the owner's already-approved budget, but not a reason to provision paid infrastructure automatically.
No paid custom domain, infrastructure, phone number, messaging account or new subscription is authorized by this package. redline.alkatek.com DNS is not configured. Public product publication and multi-owner account launch are separate from the private review deployment.