Project 12: Deployed Multi-Session Operations Decision App

Deploy a secured, read-only Livebook App that combines bounded operational data, SLA evidence, human-owned decision support, private notes, durable handoff exports, and repeatable rollback.

Quick Reference

Attribute	Value
Difficulty	Level 4 — Expert
Time Estimate	35–50 hours
Language	Elixir and bounded parameterized SQL; packaged JavaScript only for optional custom UI
Prerequisites	Projects 5–11 or equivalent data, Kino, Nx, runtime-security, Docker, and operations experience
Key Topics	Livebook Apps, multi-session isolation, read-only data access, authentication, secrets, stamping, app servers, CI deployment, capacity, observability, rollback

1. Learning Objectives

By completing this project, you will:

Convert a replayable notebook into a code-hidden multi-session application without confusing presentation with sandboxing.
Draw a complete authority and state-ownership map before implementing the UI.
Keep operational access in a standalone runtime through least-privilege, bounded, read-only database/API interfaces.
Separate private session state, immutable shared reference data, durable evidence, and deployment configuration.
Integrate an optional model suggestion with provenance, abstention, and human accept/correct/skip behavior.
Configure authentication, authorization expectations, shared secrets/storage, stamps, and audit evidence without exposing values.
Measure cold start, warmup, session memory, shared resource memory, load, inactivity shutdown, and source freshness.
Deploy an immutable notebook revision through a repeatable staging-to-production path.
Define smoke tests, health dimensions, alerts, rollback triggers, and a tested previous-revision rollback.
Prove that the completed production path has no mutation, attached runtime, arbitrary query, arbitrary code, or unrestricted production-shell capability.

2. Theoretical Foundation

2.1 Core Concepts

A deployed notebook is an executable service. App mode hides selected source and exposes rendered outputs, but the runtime still has operating-system, network, secret, and dependency authority. Security begins with what the runtime can access, not what the browser can see.

Multi-session is an isolation and capacity decision. Each user or workflow gets a separate notebook session. Private filters, uploads, notes, and outputs should remain in that session. Shared immutable model or reference resources may be centralized only when their lifecycle and privacy behavior are proven. Every active session consumes processes and memory, so concurrent-session capacity is a first-class design input.

State needs explicit ownership and lifetime. Private session state disappears when a session stops unless exported or written to an approved durable store. Shared cache state must never contain user content. Durable handoff evidence belongs in an external read/write store with an intentionally scoped credential; operational source systems remain read-only. Deployment settings and secrets belong outside notebook source.

Authentication is not authorization. Authentication identifies the app user. Authorization determines which environment, incident group, or dataset that identity may access. Livebook Teams and supported identity providers can protect the app surface, but the app still needs an explicit mapping from identity context to permitted read-only operations. Database credentials must not inherit browser authority implicitly.

Read-only must exist at several layers. The notebook UI exposes a fixed query/runbook catalog. Requests are parameterized and bounded. The database/API credential itself lacks mutation capability. The runtime is standalone, not attached. The final application contains no arbitrary SQL, Remote Execution, attached-node evaluation, shell, dynamic MFA, or mutating endpoint.

Freshness and process health differ. An app server can be healthy while its data is stale, a model is unavailable, or a query source is partially failing. Render revision, source mode, observed-at time, data age, last successful refresh, and failure status separately. Never convert missing data into a reassuring zero.

Deployment needs evidence and reversal. A production-ready notebook names its Git revision, dependency resolution, stamp authority, app-server image, model revision, source contract, clean-replay result, two-client isolation, memory budget, smoke result, and rollback target. Promotion should deploy the reviewed immutable revision; rollback should be a tested normal operation.

2.2 Why This Matters

Internal operations tools often begin as scripts or privileged dashboards and gradually become business-critical without gaining production controls. Livebook can shorten the path from analysis to usable application, but speed is safe only when runtime authority, identity, data limits, privacy, capacity, and rollback are made explicit. This project demonstrates a disciplined path: a rich decision surface backed by narrow read-only interfaces rather than a disguised production shell.

2.3 Historical Context / Background

Livebook Apps turn notebook outputs and Kino interactions into code-hidden web applications. Single-session apps share one live session; multi-session apps create independent sessions suited to private forms and workflow automation. Livebook Teams adds managed deployment groups, authentication options, organizational stamps, synchronized secrets and storage, and audit capabilities. CLI deployment supports CI/CD. Current official references include Deploy Livebook Apps, CLI deployment, production app-server guidance, authentication, shared secrets, shared storage, and stamping.

2.4 Common Misconceptions

“Code hidden means code sandboxed.” It changes presentation, not runtime authority.
“Authenticated users may all run the same queries.” Authorization still needs environment and data-scope policy.
“Read-only UI makes the system read-only.” Credential, API, runtime, and operation catalog must enforce it.
“Multi-session automatically protects every shared process.” A shared cache or serving process can still mix private content.
“A green health endpoint means current data.” Process health and source freshness are separate.
“A stamp proves business logic is safe.” It preserves authority/resource approval context, not semantic correctness.
“Rollback is just deploying an old file.” The old revision must remain compatible with current secrets, storage, schema, and app-server configuration.

3. Project Specification

3.1 What You Will Build

Build a multi-session operations decision app with these panels:

Environment and provenance header: environment, app revision, runtime mode, data age, source mode, optional model revision, and health dimensions.
Incident queue: at most 100 read-only, authorization-filtered incidents with severity, owner, status, and freshness.
SLA evidence: bounded summary cards and charts for availability, error rate, p50/p95/p99 latency, saturation, and comparison window.
Decision assistant: a reviewed runbook catalog and optional model suggestion with evidence, abstention, and human accept/correct/skip.
Private notes: session-local notes clearly labeled ephemeral until the user exports.
Handoff export: a sanitized, durable report containing user-approved evidence, provenance, decisions, and checksums but no secret or forbidden data.
Deployment evidence: clean replay, stamp authority, named secret/storage resources, image digest, warmup, capacity, smoke tests, and rollback revision.

The production deployment uses a standalone runtime and only read-only bounded operational integrations. A separate scoped write credential may write sanitized handoff reports to a dedicated evidence store; it must have no authority over production application data.

3.2 Functional Requirements

Authentication gate: no app panel renders operational content before identity is established.
Authorization filter: identity context maps to allowed environment/service scope; denial is explicit and audited.
Session isolation: forms, filters, uploads, notes, results, and exports remain private to the authenticated session.
Read-only catalog: only fixed, parameterized, bounded data queries and diagnostic guidance exist.
Freshness: every data panel includes source timestamp, observed-at timestamp, and stale/partial state.
Data limits: query timeout, row cap, byte cap, comparison-window cap, and refresh minimum are enforced.
Decision policy: optional model output preserves raw score, provenance, threshold, abstention, and human action separately.
Durable export: only sanitized user-approved evidence enters the dedicated handoff store; export is idempotent.
Revision evidence: UI and export identify notebook/app revision, data contract, query catalog, and model revision.
Failure states: unauthorized, source unavailable, stale, partial, empty, query timeout, model unavailable, overloaded, and export failed are distinct.
Deployment: staging and production deploy the same reviewed immutable notebook revision.
Rollback: previous revision is retained and successfully redeployed through the same smoke gate.

3.3 Non-Functional Requirements

Security: no production mutation, attached runtime, arbitrary SQL/source/MFA, shell, or credential display.
Privacy: cross-session canary scan passes for UI, cache, logs, exports, and shared serving resources.
Availability: one slow source or optional model cannot freeze the app; partial read-only evidence remains clearly labeled.
Performance: initial readiness, query latency, rendering, memory, and concurrent-session limits meet declared budgets.
Reproducibility: dependency, source-contract, query, model, and notebook revisions are recorded.
Accessibility: controls have labels; status is not conveyed only by color; tables and charts have textual summaries.
Auditability: authentication/authorization outcome, selected catalog action, revision, time, and result status reach a durable audit sink without private payloads.
Recoverability: cold start and rollback work without live package/model downloads.

3.4 Example Usage / Output

OPERATIONS DECISION APP
Environment: PRODUCTION (read-only)
App revision: 9b73c2a
Runtime: standalone
Authenticated scope: payments / viewer
Data observed at: 2026-07-15T19:03:12Z
Data age: 41 seconds [CURRENT]
Model: optional-triage-r17 [READY]
Mutation capability: NONE

INCIDENT INC-TRAINING-SHAPE
Evidence window: 30 minutes
Requests: 8,241,993
Availability: 99.94%
Error rate: 0.37%
p50 / p95 / p99: 42 / 211 / 804 ms
Source status: PARTIAL — saturation feed delayed 73 seconds

Model suggestion: dependency_degradation (score 0.74)
Policy: ABSTAIN — below decision threshold 0.80
Human action: investigate dependency runbook

3.5 Real World Outcome

After authentication, two test users open separate multi-session app sessions. Their queue scope follows authorization policy. Distinct note, filter, upload, and export canaries never cross sessions. Shared reference data and an optional shared serving process contain no user content.

The UI looks and behaves as follows:

┌─────────────────────────────────────────────────────────────────────┐
│ PROD READ-ONLY | Data age 41s | App 9b73c2a | Model r17 | READY    │
├────────────────┬────────────────────────────┬───────────────────────┤
│ Incident queue │ SLA and service evidence   │ Decision assistant    │
│ severity/owner │ latency/errors/saturation  │ suggest/correct/skip  │
│ max 100 rows   │ bounded comparison window  │ human owns decision   │
├────────────────┴────────────────────────────┴───────────────────────┤
│ Private notes | read-only runbook | provenance | export handoff    │
└─────────────────────────────────────────────────────────────────────┘

The staging deployment gate produces:

DEPLOYMENT GATE
clean-runtime replay ................ PASS
source and dependency review ........ PASS
expected team stamp authority ....... PASS
secret names / no values ............ PASS
read-only integration capability .... PASS
two-user isolation canaries ......... PASS
cold start / warmup budget .......... PASS
session memory and load budget ....... PASS
stale/partial/empty failure states ... PASS
handoff idempotency ................. PASS
previous-revision rollback .......... PASS
production mutation paths ........... NONE

Only after the same immutable revision passes staging may it be promoted. Production verification remains read-only.

4. Solution Architecture

4.1 High-Level Design

AUTHORS                          APP USERS
   │                                 │
   │ strong authoring identity       │ OIDC/Teams authentication
   v                                 v
┌────────────────┐          ┌────────────────────────────┐
│ Authoring      │ review   │ Livebook app server        │
│ Livebook/Git   │─────────▶│ multi-session app surface  │
└───────┬────────┘ deploy   └──────────────┬─────────────┘
        │                                  │ one standalone runtime/session
        v                                  v
┌────────────────┐          ┌────────────────────────────┐
│ CI + immutable │          │ private session state      │
│ notebook rev   │          │ filters, notes, results    │
└────────────────┘          └───────┬─────────┬──────────┘
                                    │         │
                          read-only │         │ sanitized idempotent export
                                    v         v
                         ┌────────────────┐  ┌──────────────────┐
                         │ Ops DB/API     │  │ Handoff store    │
                         │ bounded reader │  │ dedicated writer │
                         └────────────────┘  └──────────────────┘
                                    │
                         optional   v
                              ┌──────────────┐
                              │ ML serving   │ immutable model,
                              │ no user cache│ bounded queue
                              └──────────────┘

Durable audit receives identity metadata, catalog action, revision, time,
and outcome—not query payloads, notes, image bytes, or secrets.

4.2 Key Components

Component	Responsibility	Key Decisions
Notebook/app document	Define UI, orchestration, evidence, and app settings	Keep stable domain modules in a normal package when complexity grows
Identity adapter	Read authenticated context and derive app authorization scope	Deny on missing or ambiguous identity
Query catalog	Provide fixed read-only operational views	Parameterized, timed, capped, versioned
Data adapter	Normalize DB/API results and freshness	Never treat missing source as zero
Session coordinator	Own private filters, notes, current request, and UI state	Per-session only; discard on inactivity unless exported
Shared reference cache	Hold immutable public/reference metadata	No user payload, query result, or note allowed
Optional Nx.Serving	Batch approved model inference	Immutable artifact; bounded queue; no retained content
Handoff exporter	Create sanitized idempotent durable evidence	Dedicated store credential unrelated to production DB
Audit emitter	Record identity metadata and operation outcome	External durable sink, payload-minimized
Deployment pipeline	Deploy reviewed revision and preserve rollback	Same artifact through staging and production

4.3 Data Structures

authorization_context = {
  authenticated_subject_id,
  groups_or_roles,
  allowed_environments,
  allowed_services,
  identity_source
}

session_state = {
  session_request_id,
  filters,
  selected_incident,
  current_generation,
  private_notes,
  latest_bounded_evidence,
  human_decision,
  export_status
}

evidence_manifest = {
  app_revision,
  query_catalog_revision,
  source_contract_revision,
  model_revision_optional,
  observed_at,
  source_freshness,
  redaction_policy_revision,
  checksums,
  human_decision
}

deployment_record = {
  notebook_revision,
  app_server_image_digest,
  dependency_manifest,
  stamp_authority,
  deployment_group,
  smoke_result,
  capacity_result,
  rollback_revision
}

Do not store secret values, raw authorization tokens, database connection strings, private notes, or user uploads in deployment or audit records.

4.4 Algorithm Overview

Key Algorithm: Authorized Read-Only Decision Workflow

Establish authenticated app identity and derive allowed environment/service scope.
Validate the requested catalog view, incident, filters, and time window against that scope.
Allocate a request generation and render a loading state with prior evidence marked stale.
Execute bounded read-only sources concurrently under supervised deadlines.
Normalize results with observed-at time, source freshness, and partial-failure markers.
Build bounded Explorer summaries and render cards/charts/tables.
Optionally submit a bounded suggestion request; retain model provenance and raw score.
Apply suggest/abstain policy and capture human action separately.
Update UI only if the generation is current.
On explicit export, sanitize selected evidence, compute an idempotency key, write to the dedicated handoff store, and record metadata in audit.
On session shutdown, discard private state and verify shared caches contain no session content.

Complexity Analysis:

Query and aggregation cost: bounded by catalog-specific time/row/byte contracts; local summaries O(R log R) at worst for capped R.
Rendering cost: O(K) for bounded cards/chart points/table rows.
Per-session memory: O(K + notes bound + UI state), plus any explicitly measured per-session model preprocessing.
Shared model memory: architecture-dependent and measured separately from session memory.

5. Implementation Guide

5.1 Development Environment Setup

Use separate development, staging, and production configuration with distinct credentials. Development may use synthetic fixtures. Staging must mirror production authorization and schemas while containing safe data. Production credentials must be read-only for operational sources.

Environment contract
  development: synthetic/local data; no production route
  staging: production-like schema; read-only; test identities
  production: standalone runtime; bounded read-only source roles

Secret resources by name only
  OPS_READONLY_DATABASE
  OPS_READONLY_API_TOKEN
  HANDOFF_EVIDENCE_STORE
  OPTIONAL_MODEL_STORE

Forbidden in notebook source/output
  passwords, tokens, connection strings, Teams keys, cookies, raw identity claims

Use Docker and a Livebook Teams deployment group according to the current official deployment guide. CI deployment should reference protected environment secrets and the reviewed notebook path; do not embed a complete credential-bearing command in the notebook or this guide.

5.2 Project Structure

deployed-ops-app/
├── notebooks/
│   └── operations-decision-app.livemd
├── lib/
│   ├── authorization_policy.ex
│   ├── query_catalog.ex
│   ├── source_adapter.ex
│   ├── freshness.ex
│   ├── decision_policy.ex
│   ├── handoff_export.ex
│   └── audit_event.ex
├── test/
│   ├── authorization_policy_test.exs
│   ├── query_catalog_test.exs
│   ├── session_isolation_test.exs
│   ├── redaction_test.exs
│   └── handoff_export_test.exs
├── fixtures/
│   ├── incidents.json
│   ├── sla-snapshots.parquet
│   └── source-failure-scenarios.json
├── deploy/
│   ├── app-server-contract.md
│   ├── dependency-manifest.locked
│   ├── smoke-test.md
│   └── rollback-runbook.md
├── evidence/
│   └── deployment-record-schema.json
└── README.md

5.3 The Core Question You’re Answering

“What must change when an executable notebook becomes a multi-user service that influences operational decisions?”

The answer includes identity, authorization, runtime authority, session isolation, durable state, freshness, model governance, capacity, observability, immutable deployment, and rollback. App preview alone is not completion.

5.4 Concepts You Must Understand First

App and session semantics
- Which state is private per session and what may be shared?
- Primary references: Livebook Apps deployment and Kino.Workspace
Runtime authority
- Why must this app use a standalone runtime and narrow interfaces?
- Primary reference: Livebook runtimes
Authentication and authorization
- Which identity provider protects the app, and how is scope derived?
- Primary reference: Livebook authentication
Secrets, storage, and stamps
- Which resources are synchronized, approved, and environment-specific?
- Primary references: shared secrets, shared storage, and stamping
App-server capacity
- How do base server, session, data, and model memory combine?
- Primary reference: production app-server guidance
Repeatable deployment
- How does CI promote one immutable revision and preserve rollback?
- Primary reference: CLI deployment
Decision support
- How do freshness, uncertainty, abstention, and human override affect action?
- Book reference: AI Engineering — evaluation and inference chapters

5.5 Questions to Guide Your Design

Which state is session-private, immutable shared cache, durable handoff, deployment config, and audit metadata?
How are authenticated groups mapped to allowed environments and services?
What independent enforcement makes operational data read-only?
Which source failure produces stale, partial, empty, or failed UI state?
Can a late query result overwrite a newer filter generation?
Does any shared process retain user content after a request?
What cold-start and per-session memory budget follows from the expected concurrency?
What exact smoke failure triggers automatic or manual rollback?
Can the previous revision still use current secrets, storage, schemas, and model artifacts?
What evidence proves production contains no mutation path?

5.6 Thinking Exercise

Create a state and authority matrix before building the UI:

Actor/component	Identity	Reads	Writes	Credential	Lifetime	Durable evidence
App user	authenticated subject	authorized app views	private session controls	app identity	session	metadata only
Session runtime	app revision	read-only ops sources	sanitized handoff only	scoped resources	session	revision/outcome
Query catalog	app code	approved schemas/APIs	none	read-only source credential	revision	query ID/status
Shared cache	app server	immutable reference data	cache refresh	source reader	server	freshness only
Handoff exporter	app code	selected sanitized evidence	dedicated evidence store	write-only/scoped store credential	request	checksum/location
CI	protected automation	notebook artifact	deployment group	deploy token	pipeline	deployment record

Add database, model store, audit sink, author, and app server. If any row has ambiguous write authority, stop and redesign.

5.7 The Interview Questions They’ll Ask

“How do single-session and multi-session Livebook Apps differ?”
“Why does code-hidden app mode not sandbox notebook execution?”
“How do you prevent shared caches or model serving from leaking user data?”
“How do authentication and authorization differ in this app?”
“What does a notebook stamp guarantee and not guarantee?”
“How do you size, deploy, observe, and roll back a Livebook App?”
“How do you prove a production operations tool is read-only?”

5.8 Hints in Layers

Hint 1: Begin with authority, not layout

Select standalone runtime, read-only source credentials, authorization scope, and durable evidence store before drawing cards.

Hint 2: Treat each session as disposable

Private notes and filters live in the session until explicitly exported. Never rely on session memory for durable operational decisions.

Hint 3: Make stale and partial visible

Attach freshness to each source. Do not let a healthy app process hide an old or failed feed.

Hint 4: Promote evidence, not hope

Clean replay, two-user canaries, cold start, memory, load, redaction, smoke, and rollback must pass on the exact revision.

5.9 Books That Will Help

Topic	Book	Chapter
Production stability and capacity	Release It!, 2nd ed.	Stability, capacity, and operations chapters
Architecture trade-offs	Fundamentals of Software Architecture	Architecture characteristics and risk chapters
Data reliability	Designing Data-Intensive Applications, 2nd ed.	Chapters 1, 3, and 11
Model-backed decisions	AI Engineering	Evaluation and inference chapters
Continuous delivery	Continuous Delivery by Jez Humble and David Farley	Deployment pipeline and release strategy chapters

5.10 Implementation Phases

Phase 1: Authority, Contracts, and Fixtures (8–11 hours)

Goals: prove read-only architecture and build testable domain components before app mode.

Tasks:

Complete trust, state, credential, and data-flow maps.
Define authorization policy and fixed query catalog.
Build stale, partial, empty, timeout, unauthorized, and overload fixtures.
Define evidence, redaction, audit, and idempotent handoff schemas.
Define optional model provenance and abstention policy.

Checkpoint: normal Mix tests prove authorization, bounds, redaction, and no mutation capability.

Phase 2: Multi-Session App Experience (9–13 hours)

Goals: build private session workflow and honest operational presentation.

Tasks:

Implement identity/scope gate and session coordinator.
Add bounded queue, SLA evidence, failure states, and generation control.
Add private notes and optional model suggestion/human correction.
Add sanitized idempotent export.
Run two-client canary and inactivity cleanup tests.

Checkpoint: app preview meets all privacy, freshness, and read-only interaction requirements.

Phase 3: App Server, Capacity, and Staging (9–13 hours)

Goals: operate the app as a service before production promotion.

Tasks:

Configure Teams workspace, expected stamp authority, deployment group, authentication, secrets, and storage.
Build immutable app-server image/dependency/model artifacts.
Measure cold start, warmup, base memory, per-session memory, shared resources, and load.
Configure inactivity shutdown and health/freshness metrics.
Deploy the reviewed revision to staging and run smoke tests.

Checkpoint: staging gate passes with recorded image digest and capacity margin.

Phase 4: Promotion, Observation, and Rollback (9–13 hours)

Goals: prove deployment and recovery rather than simply publishing.

Tasks:

Promote the same immutable revision through repeatable CI/manual deployment.
Run production read-only smoke checks and audit verification.
Freeze one source and verify freshness alarms while process health stays green.
Redeploy the previous revision and repeat the gate.
Restore the candidate revision only after rollback evidence is captured.

Checkpoint: production read-only verification and previous-revision rollback both pass.

5.11 Key Implementation Decisions

Decision	Options	Recommendation	Rationale
App mode	Single-session; multi-session	Multi-session	Private filters, notes, and workflows require isolation
Runtime	Attached; standalone	Standalone	Narrows authority and preserves dependency isolation
Operational access	Arbitrary SQL/remote code; fixed read-only catalog	Fixed catalog + read-only credential/API	Enforces safety beyond UI promises
Notes	Shared cache; session-local with explicit export	Session-local	Prevents cross-user leakage
Durable export	Production DB; dedicated evidence store	Dedicated evidence store	Separates handoff writing from operational data authority
Model	Mandatory and authoritative; optional suggestion	Optional suggestion with abstention/human override	App remains useful and honest without model
Deployment	Mutable “latest”; immutable revision	Immutable revision through staging	Makes rollback and evidence reliable
Dependencies/model	Download at startup; prewarmed immutable artifacts	Prewarmed	Improves cold start and offline recoverability

6. Testing Strategy

6.1 Test Categories

Category	Purpose	Examples
Authorization	Prevent cross-scope access	role/service/environment matrix, denied identity
Query/data contract	Bound operational work	parameters, row/byte/time limits, stale/partial sources
Session isolation	Protect private state	two-user filters, notes, uploads, outputs, exports
Shared-resource privacy	Keep caches/serving safe	user-content canary scans after batching/cache refresh
Decision	Preserve human authority	abstain, model unavailable, accept/correct/skip
Export/audit	Prove durable safe evidence	redaction, idempotency, audit metadata, failure retry
Capacity	Size app server	cold start, memory/session, concurrency, inactivity shutdown
Deployment	Prove promotion and reversal	staging smoke, immutable revision, rollback compatibility
Security	Prove read-only path	credential permissions, no dynamic SQL/code, no attached runtime

6.2 Critical Test Cases

Unauthenticated user: receives no operational content.
Unauthorized scope: a valid user cannot request another service/environment by changing input.
Two-user canaries: notes, filters, model inputs, outputs, and exports remain isolated.
Shared cache scan: no user canary appears in shared state after requests finish.
Late result: an older slow query cannot overwrite a newer filter generation.
Stale source: process health stays ready while UI changes to stale and alarms.
Partial source: valid panels remain visible with explicit missing-source context.
Read-only enforcement: source credential and API reject mutation independently of notebook behavior.
Model unavailable: app remains usable, reports model failure, and allows human-only decision.
Handoff idempotency: retry produces one durable report identity, not duplicates.
Cold offline start: approved dependencies/model are available without runtime internet fetch.
Capacity threshold: excess sessions receive bounded refusal/degradation rather than memory exhaustion.
Rollback: previous revision deploys and passes authentication, secrets, storage, schema, and smoke checks.
Mutation-path scan: source, dependencies, configuration, UI, and network observations show no production write/attached/remote-code path.

6.3 Test Data

Identity fixtures:
  payments_viewer, catalog_viewer, unauthorized_user, missing_identity

Source fixtures:
  current, stale, partial, empty, timeout, oversized, schema_mismatch

Session canaries:
  user-A-note, user-B-note, user-A-upload, user-B-upload

Decision fixtures:
  high suggestion, low/abstain, tie, model unavailable, human correction

Deployment fixtures:
  candidate revision, previous revision, secret-name manifest,
  app-server image digest, expected stamp authority

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

Pitfall	Symptom	Solution
Shared input/frame used	Users see another session’s data	Multi-session controls plus two-user canary tests
UI says read-only but credential writes	Hidden mutation capability remains	Use independently read-only credential/API
App healthy, data old	Operators trust stale evidence	Separate runtime health and source freshness
Model copied per session	Memory rises sharply with users	Measure architecture; share only immutable serving resources safely
Startup downloads dependencies/model	Slow or failed restart without network	Prewarm and verify immutable artifacts
Notes stored in shared cache	Cross-user privacy leak	Keep private state in session; export explicitly
Rollback cannot access storage	Old revision incompatible with current environment	Version deployment contract and rehearse rollback in staging
Audit contains payloads/secrets	Privacy/security incident	Emit minimal metadata and scan with seeded canaries

7.2 Debugging Strategies

Start at the header: verify environment, revision, runtime, identity scope, source time, and model version.
Trace one request generation: authentication -> authorization -> query -> normalize -> render -> export.
Compare session and app-server memory: identify accidental per-session model/cache copies.
Freeze dependencies one at a time: distinguish stale data, model failure, and app-process failure.
Use two real authenticated test identities: one browser is insufficient evidence.
Inspect source credentials externally: do not rely only on notebook claims of read-only access.
Replay the previous revision: rollback failures are usually environment-contract drift.

7.3 Performance Traps

Avoid querying raw production-scale rows for every filter, rendering millions of points, refreshing faster than source change, compiling dependencies or model shapes per session, retaining unbounded notes/logs, and allowing multi-session count to exceed measured memory. Use bounded pre-aggregation, explicit cache keys containing no user data, fixed serving shapes, and inactivity shutdown where workflow permits.

8. Extensions & Challenges

8.1 Beginner Extensions

Add a downloadable provenance-only report with no operational row data.
Add an accessibility audit and text equivalent for every chart.
Add a visible “why this result is stale/partial” explainer.

8.2 Intermediate Extensions

Add a second read-only source with independent freshness and partial-failure behavior.
Add an app folder and versioned operator handbook for a team deployment.
Add a model-free rules suggestion and compare it with optional ML evidence.

8.3 Advanced Extensions

Scale app servers across a deployment group and measure session routing, capacity, and shared-resource assumptions.
Add a dedicated inference service behind an authenticated bounded API, keeping the Livebook app free of model memory.
Add signed handoff artifacts and retention/lifecycle policy in the dedicated evidence store.
Add automated dependency/model vulnerability and license checks to the deployment gate.

Production mutation is deliberately excluded from all extension levels. A separate project and governance review would be required.

9. Real-World Connections

9.1 Industry Applications

Incident decision support: combine freshness-aware telemetry with a reviewed diagnostic guide.
Customer-support consoles: expose bounded read-only account evidence and private handoff notes.
Data-quality operations: review pipeline health and generate sanitized remediation tickets.
ML-assisted review: suggest categories while preserving human judgment and model provenance.
Compliance evidence: generate reproducible, redacted, revision-identified reports.

Livebook: notebook apps, runtimes, deployment, and collaboration.
Kino: multi-user inputs, frames, screens, and app context.
Explorer: bounded analytical summaries.
Nx and Bumblebee: optional model-serving layer.
KinoDB: database integration patterns for Livebook.

9.3 Interview Relevance

This capstone supports senior-level discussion of trust boundaries, multi-tenancy, identity, authorization, secrets, data contracts, stale/partial states, model governance, capacity, deployment pipelines, observability, incident readiness, audit minimization, and rollback.

10. Resources

10.1 Essential Reading

Deploy Livebook Apps — deployment groups, app servers, preview, and update flow.
Deploy via CLI — repeatable CI/CD deployment.
Production app servers — dependency persistence, session memory, and inactivity shutdown guidance.
Livebook authentication — supported identity controls.
Livebook shared secrets — team secret synchronization and encryption model.
Livebook shared file storage — synchronized Git/S3-compatible storage behavior.
Notebook stamping — remembered resource approval and its limits.
Kino.Workspace — app/session and user context.
Release It!, 2nd ed. — stability, capacity, and production operations.

10.2 Video Resources

Follow the current official deployment tutorial media embedded in the Livebook Apps documentation.
Use current Livebook Teams demonstrations at Livebook Teams for SSO, deployment, production access, and audit concepts.
Prefer official release demonstrations at Livebook News for multi-session app behavior.

10.3 Tools & Documentation

Docker: immutable app-server packaging and offline restart tests.
Livebook Teams deployment group: authenticated staging and production app servers.
Protected CI environment: deploy token and Teams key storage.
Structured log/audit sink: durable minimal metadata outside session memory.
Load generator with two authenticated identities: session isolation and capacity verification.
Artifact/canary scanner: detect secret and cross-session leakage in notebook, logs, caches, and exports.

Project 6: Safe SQL Incident Investigation Runbook: provides the fixed read-only catalog foundation.
Project 7: Interactive SLA Command Center: provides freshness-aware analytics and request generations.
Project 8: Portable Cloud Data Lake Lab: provides shared storage, secret, and provenance discipline.
Project 9: Tested Domain Smart Cell Toolkit: provides transparent reusable editors.
Project 10: Nx + Bumblebee Image Triage Lab: provides optional model suggestion and human override.
Project 11: Safe Attached-Runtime Triage Console: explains why this production app returns to standalone and narrow read-only interfaces.

11. Self-Assessment Checklist

11.1 Understanding

I can explain why app mode is not a sandbox.
I can classify every state item by owner, sharing, durability, and lifetime.
I can explain authentication, authorization, source credential, and audit identity separately.
I can prove why production integrations are read-only at more than one layer.
I can explain capacity and rollback using measured evidence.

11.2 Implementation

Authentication, authorization, session isolation, and two-user canaries pass.
Query catalog, source bounds, freshness, and failure states pass.
Optional model suggestion preserves abstention and human authority.
Handoff export is sanitized, idempotent, and separate from operational data authority.
Staging, capacity, immutable deploy, production read-only smoke, and rollback pass.
No production mutation, attached runtime, arbitrary query, or arbitrary code path exists.

11.3 Growth

I documented one feature deliberately excluded because it widened authority.
I can hand the rollback runbook to another operator without private instructions.
I can explain which notebook modules should graduate into a maintained Mix service.
I can defend the app’s freshness, privacy, capacity, and model-governance policies in an architecture review.

12. Submission / Completion Criteria

Minimum Viable Completion:

A local multi-session app preview authenticates test identity context, isolates two sessions, reads a bounded synthetic/read-only source, shows freshness, and exports a sanitized handoff.
Runtime is standalone and no mutation path exists.

Full Completion:

Authorization scope, fixed query catalog, stale/partial/empty/failure states, optional human-owned model suggestion, shared-resource privacy, idempotent export, durable audit metadata, Teams authentication/configuration, shared secrets/storage, expected stamp authority, offline cold start, capacity/load, immutable staging/production deployment, and previous-revision rollback all pass.
Production verification uses only bounded read-only operations.

Excellence (Going Above & Beyond):

Operate multiple app servers with measured capacity and recovery, externalize model inference behind a narrow service, add signed/lifecycle-managed handoff artifacts, automate dependency/model policy checks, and demonstrate a disaster-recovery rehearsal—while preserving the no-production-mutation rule.

This guide was generated from LEARN_LIVEBOOK_ELIXIR_DEEP_DIVE.md. For the complete learning path, see the parent guide.

Project 12: Deployed Multi-Session Operations Decision App

Quick Reference

1. Learning Objectives

2. Theoretical Foundation

2.1 Core Concepts

2.2 Why This Matters

2.3 Historical Context / Background

2.4 Common Misconceptions

3. Project Specification

3.1 What You Will Build

3.2 Functional Requirements

3.3 Non-Functional Requirements

3.4 Example Usage / Output

3.5 Real World Outcome

4. Solution Architecture

4.1 High-Level Design

4.2 Key Components

4.3 Data Structures

4.4 Algorithm Overview

5. Implementation Guide

5.1 Development Environment Setup

5.2 Project Structure

5.3 The Core Question You’re Answering

5.4 Concepts You Must Understand First

5.5 Questions to Guide Your Design

5.6 Thinking Exercise

5.7 The Interview Questions They’ll Ask

5.8 Hints in Layers

5.9 Books That Will Help

5.10 Implementation Phases

Phase 1: Authority, Contracts, and Fixtures (8–11 hours)

Phase 2: Multi-Session App Experience (9–13 hours)

Phase 3: App Server, Capacity, and Staging (9–13 hours)

Phase 4: Promotion, Observation, and Rollback (9–13 hours)

5.11 Key Implementation Decisions

6. Testing Strategy

6.1 Test Categories

6.2 Critical Test Cases

6.3 Test Data

7. Common Pitfalls & Debugging

7.1 Frequent Mistakes

7.2 Debugging Strategies

7.3 Performance Traps

8. Extensions & Challenges

8.1 Beginner Extensions

8.2 Intermediate Extensions

8.3 Advanced Extensions

9. Real-World Connections

9.1 Industry Applications

9.2 Related Open Source Projects

9.3 Interview Relevance

10. Resources

10.1 Essential Reading

10.2 Video Resources

10.3 Tools & Documentation

10.4 Related Projects in This Series

11. Self-Assessment Checklist

11.1 Understanding

11.2 Implementation

11.3 Growth

12. Submission / Completion Criteria