Session Identity Platform — WebX

Document type: Architecture + Product Intent + Implementation Record + Operational Runbook + Decision History
Status: In Development (identity/network coherence platform landed on branch codex/session-identity-platform; default policy remains backward-compatible)
Engineering owner: WebX platform / browser runtime team
Product owner: WebX product (verified browser automation)
Repository: rust_mono_browser (workspace members under crates/)
Production: https://webx.agentslab.host (live data plane; identity policy env-gated)
Last materially reviewed: 2026-08-10
Consumer portal: /docs/session-identity (guide) · /docs/session-identity-system-record (this record) · catalog /docs
Schema versions: webx.session-identity.v1, webx.fingerprint.v1, policy version coherent-v1
Canonical code:

• crates/webx-server/src/session_identity.rs
• crates/webx-server/src/proxy_manager.rs
• crates/webx-server/src/contexts.rs
• crates/webx-server/src/run_launch.rs
• crates/webx-browser/src/stealth.rs
  Acceptance IDs: UAT-047 … UAT-054 (uat/manifest/v1/uat-manifest.json)

0. Executive Summary

What did we build?

A Session Identity Platform that composes browser fingerprint, managed proxy lease, geography, DNS mode, Chrome build, and persistence policy into one authoritative SessionIdentity document per session. Launch paths derive user-agent, locale, timezone, and egress from that structure instead of inventing independent facts. Persistent browser contexts store a secret-free webx-network-identity.json so cookie reuse also rebinds a compatible network family. Failover prefers minimum identity distance and fails closed when no safe route exists.

Why does it exist?

Logged-in portal automation fails trust and reliability when the browser “looks like” one place (UA, timezone, locale) while traffic exits another (proxy country), or when a retained login context silently continues over a different egress IP family. Sites treat that as fraud or bot risk; operators cannot prove what identity was actually used. The platform makes identity coherent, sticky, observable, and fail-closed under opt-in policy.

Who benefits?

What changed?

Before
Fingerprint patches, proxy leases, and persistent contexts were loosely coupled. Callers could request US proxy with a DE timezone; sticky contexts could reuse cookies while picking a different egress; failover could jump countries; receipts could not prove a coherent identity.

After
SessionIdentity::compose is the single composition point. WEBX_IDENTITY_POLICY=permissive|coherent|strict controls fail-closed behavior (default permissive for backward compatibility). Managed proxy acquisition honors preferred_lease_hash and identity distance (MAX_SAFE_IDENTITY_DISTANCE = 50; country change costs 100 → always unsafe). Context reuse under coherent/strict requires a compatible managed lease when prior network identity is concrete. Post-egress observation re-validates without fabricating exit country.

Current state

One-sentence architecture

Client / agent task → run_launch / Browserbase session create → SessionIdentity compose + ProxyManager.acquire → Chrome launch (fingerprint + profile dir) + egress lease → observation / drift / provenance on run manifest → durable logs & receipts.

1. Product Intent

Engineering decisions start with the outcome being created, not the technology selected.

1.1 Problem statement

User problem
Operators running logged-in third-party portals (invoices, compliance, supplier systems without APIs) need a browser session that stays the same person across steps and restarts: same cookies, same geography, same browser surface — and honest failure when that cannot be guaranteed.

Business problem
Without coherent identity, automation flunks anti-fraud checks, causes support load, and weakens WebX’s differentiator (verified, auditable runs). Competitors sell “browser infra”; WebX must sell trustable identity + evidence.

Technical problem
Historically independent knobs (UA spoof, proxy pool, Chrome profile dir, DNS mode) could contradict each other. Failover and context reuse could silently change network identity. Secrets risked leaking into logs/receipts if identity snapshots were naïve.

Why now?
Production authority hardening (2026-08-09), Browserbase-compatible session plane, managed proxy receipts, and multi-session persistent contexts made incoherent identity an unacceptable integrity hole before GA claims.

1.2 Target users / actors

2. Outcomes and Success Criteria

2.1 Product outcomes

2.2 Engineering outcomes

2.3 Non-goals

• NG-01 — Probabilistic fingerprint simulation, JA3/TLS stack spoofing, or “undetectable browser” marketing claims.
• NG-02 — Guaranteeing bypass of Cloudflare / reCAPTCHA / commercial bot-management (captcha path is separate).
• NG-03 — Portable persistent-context v2 (object storage, immutable CAS heads, cross-worker materialization) — listed as infrastructure-dependent.
• NG-04 — Replacing the verified-execution stack (webx-verify); identity is composition + evidence, not membrane.
• NG-05 — Inventing exit geography when geo-check is unconfigured or fails.
• NG-06 — Changing default policy to coherent for all existing tenants without an explicit product decision.

Non-goals prevent accidental architecture expansion.

3. Constraints

Hard constraints

Soft constraints

• Prefer existing platform primitives (CDP stealth, proxy pool, context store, run manifests).
• Prefer operational simplicity over theoretical multi-hop identity graphs.
• Avoid a second fingerprint framework beside FingerprintProfile.
• Prefer reversible decisions when evidence is incomplete (policy remains env-gated).
• Prefer honest null / error over fabricated coherence.

4. System Invariants

When implementation changes, these invariants should survive.

5. Scope and System Boundary

5.1 In scope

• Composition and validation of SessionIdentity
• Fingerprint profile schema and CDP application (UA, UA-CH, platform, locale, timezone, viewport, hardware, WebGL)
• Managed proxy inventory, lease, sticky key, health quarantine, identity-distance failover
• Post-egress observation and drift detection
• Persistent context network identity bind/load
• Provenance digests on run launch / run manifest
• Metrics and UAT contracts for the above
• Integration with agent task launch and Browserbase-compatible session create

5.2 Out of scope

• LLM ODEV loop internals (owned by webx-agent)
• Membrane / confirmation / receipts crypto (owned by webx-verify / receipt signing)
• Full multi-region control plane topology (see docs/MULTI_REGION.md)
• Captcha solving product claims (see docs/CAPTCHA.md)
• Residential ISP vendor commercial SLAs
• WebDriver BiDi completeness
• Tenant SSO lifecycle (OIDC/SAML/SCIM) beyond using existing project API keys

5.3 Context diagram

                 ┌──────────────────────────┐
                 │ Integrator / Agent task  │
                 └────────────┬─────────────┘
                              │ REST / WS / MCP
                              ▼
              ┌───────────────────────────────┐
              │        webx-server            │
              │  Auth → run_launch / BB API   │
              │                               │
              │  ┌─────────────────────────┐  │
              │  │ Session Identity        │  │
              │  │ Platform boundary       │  │
              │  │  compose / validate     │  │
              │  │  ProxyManager.acquire   │  │
              │  │  ContextStore bind/load │  │
              │  └───────────┬─────────────┘  │
              └──────────────┼────────────────┘
                  │          │           │
         ┌────────▼──┐  ┌────▼─────┐  ┌──▼──────────────┐
         │ Profile   │  │ Proxy    │  │ Chrome (CDP)    │
         │ disk      │  │ inventory│  │ stealth apply   │
         │ contexts/ │  │ + geo    │  │ process tier    │
         └───────────┘  └──────────┘  └─────────────────┘
                  │
                  ▼
         Run manifest / receipts / metrics / session logs

5.4 Ownership boundaries

Ambiguous ownership is an operational defect — identity composition is not owned by the LLM agent.

6. Architecture

6.1 Repository architecture

rust_mono_browser/
├── crates/
│   ├── webx-server/          # API, SessionIdentity, ProxyManager, ContextStore, launch
│   │   ├── src/
│   │   │   ├── session_identity.rs   # canonical identity domain
│   │   │   ├── proxy_manager.rs      # lease, health, failover, inventory
│   │   │   ├── contexts.rs           # persistent profile + network identity files
│   │   │   ├── run_launch.rs         # compose + acquire on task launch
│   │   │   ├── browserbase_compat.rs # /v1/sessions path
│   │   │   ├── run_manifest.rs       # provenance binding
│   │   │   ├── metrics.rs            # proxy/identity golden metrics
│   │   │   └── stealth applied via webx-browser
│   │   ├── migrations/postgres/
│   │   └── tests/
│   ├── webx-browser/         # CDP, FingerprintProfile, apply_stealth
│   ├── webx-agent/           # ODEV loop (consumer of launched session)
│   ├── webx-verify/          # membrane / txlog / receipts (adjacent)
│   ├── webx-orchestrator/    # process tier profiles, engines
│   └── …
├── clients/                  # py / ts SDK surfaces
├── docs/                     # this record, MANAGED_PROXIES, UAT_RUNBOOK, …
├── uat/
│   ├── manifest/v1/uat-manifest.json   # UAT-047..054
│   ├── contracts/test_identity_network_contracts.py
│   └── runner/
├── ops/                      # backup, SLO rules, single-node manifests
├── k8s/                      # enterprise / egress proxy examples
└── scripts/                  # live UAT / production regression helpers

6.2 Runtime architecture

Request (task or /v1/sessions)
   │
   ▼
┌────────────┐
│ Edge/Auth  │  x-api-key / Bearer / X-BB-API-Key
└─────┬──────┘
      │
      ▼
┌──────────────────┐
│ Launch handler   │  run_launch / browserbase_compat
└──────┬───────────┘
       │
       ├─ load prior ContextNetworkIdentity (if contextId)
       ├─ ProxyManager.acquire(LeaseRequest{ geo, sticky, preferred_lease_hash, budget })
       ├─ SessionIdentity::compose(…)
       ├─ IdentityValidator (policy fail-closed?)
       │
       ▼
┌────────────────┐
│ Domain service │  identity + lease + provenance
└───┬─────────┬──┘
    │         │
    ▼         ▼
┌───────┐  ┌──────────────────┐
│Context│  │ Chrome process   │
│ disk  │  │ CDP + stealth    │
└───────┘  └────────┬─────────┘
                    │ optional geo-check through proxy
                    ▼
             apply_post_egress / drift
                    │
                    ▼
         Events / Metrics / Run manifest / Logs

6.3 Request / workflow lifecycle (sticky geo session)

1. Integrator creates session with managed proxy geo + optional contextId / sticky key.
2. Auth validates API key / project scope.
3. Handler loads prior webx-network-identity.json if context exists.
4. ProxyManager.acquire selects inventory entry: prefer preferred_lease_hash, else sticky key, else geo/type match; quarantine unhealthy; enforce capacity and network budget.
5. If identity-preserving failover required and no candidate within distance ≤ 50 → NoSafeFailover / HTTP error.
6. SessionIdentity::compose builds secret-free identity; validates fingerprint schema; applies continuity rules vs prior.
7. Under coherent/strict failures → reject admission (invalid_identity_policy / coherence errors mapped to 400-class).
8. Chrome launches with profile dir + fingerprint applied via apply_stealth.
9. Optional egress verification updates observation.country via apply_post_egress (never invents).
10. Context bind writes network identity snapshot; run manifest records digests.
11. Telemetry increments acquire / validation metrics (bounded labels).
12. On teardown, lease released; proxy receipt cleared; profile flush on release paths.
13. Failure recovery: quarantine bad endpoints; do not silent country hop; operator re-runs with corrected pool/geo.

This section should make it possible to debug the system without reading every source file.

7. Data Model

7.1 Core entities

7.2 State transitions

Identity composition

REQUESTED
   │
   ▼
COMPOSE (fingerprint validate)
   │
   ├──── invalid fingerprint ────► REJECTED
   │
   ▼
VALIDATE (coherence / continuity / DNS)
   │
   ├──── policy permissive ──► ADMITTED (findings may exist)
   ├──── policy fail-closed + findings ──► REJECTED
   │
   ▼
LEASED (managed) / DIRECT
   │
   ▼
OBSERVED (optional geo-check)
   │
   ├──── strict + missing verified country ──► REJECTED
   ├──── country mismatch (coherent/strict) ──► REJECTED
   │
   ▼
BOUND_TO_CONTEXT (optional)
   │
   ▼
ACTIVE_SESSION
   │
   ├──── drift detected ──► DRIFT_FLAGGED / fail-closed per policy
   │
   ▼
RELEASED (lease cleared, profile flush)

Illegal transitions should be impossible at the type/API boundary (compose returns Result, acquire returns ProxyError).

7.3 Data ownership

8. API / Contract Design

Stable interfaces (identity-relevant)

Managed proxy request (Browserbase-shaped)

// POST /v1/sessions
{
  "proxies": [
    {
      "type": "webx",
      "geolocation": { "country": "US", "state": "CA", "city": "SAN_FRANCISCO" },
      "rotation": "per_session",
      "stickyKey": "login-flow-7"
    }
  ]
}

External proxy still supported verbatim (type: external).

Contract concerns

Error semantics (identity / proxy)

Domain codes include: invalid_identity_policy, identity_continuity, identity_drift, proxy_geo_unverified, no_safe_failover, managed_proxy_unavailable.

9. Critical User Journeys

Journey J-01 — Geo-pinned Browserbase session

Journey J-02 — Persistent login context with network continuity

Journey J-03 — Identity-preserving proxy failover

Journey J-04 — Cross-context isolation

10. Non-Functional Requirements

10.1 Reliability

10.2 Performance

Scale assumptions

10.3 Scalability

10.4 Availability vs consistency

This workflow prefers consistency (coherence) of browser+network identity over availability of “any browser that starts.”

Under coherent/strict, WebX will refuse a session rather than admit a contradictory identity. Under default permissive, availability of existing clients is preferred and findings do not block admission.

11. Failure Model

Failure analysis

Partial failure specifics

Retry behavior

12. Security and Privacy

Threat model — assets

• Proxy credentials (inventory secrets)
• Customer cookies / logged-in portal state (context profiles)
• Session tokens / API keys
• Network observations (exit IP, ASN, country)
• Fingerprint profiles (deployment config)
• Run artifacts (screenshots, logs, receipts)

Threats

Trust boundaries

Browser / integrator client
   │ UNTRUSTED
   ▼
Public API (auth required)
   │ authenticated boundary
   ▼
webx-server application (compose, acquire, launch)
   │ controlled boundary
   ▼
Chrome process / proxy egress / disk profiles / Postgres

Never trust client-side enforcement as authorization. Never treat client-supplied “observed country” as verified without server-side check.

Security controls

Sensitive-data rule

Treat as potentially public if placed in: browser bundle, public/, frontend env, public repository, downloadable artifacts, client-visible logs.
Therefore: proxy passwords and raw authenticated proxy URLs never appear in SessionIdentity, receipts, or webx-network-identity.json.

13. Observability

13.1 Logs

Logs should answer: what happened, for which request/session/project, which component (compose/acquire/stealth), duration, retry/quarantine, error code, correlation across services.

Recommended context fields: request_id, session_id, project_id / tenant, operation, duration_ms, result, error_code, proxy_provider (not password), identity_policy, lease_hash (not credentials).

Never log secrets. Exit IPs only in controlled durable fields, not high-cardinality metrics.

13.2 Metrics

Golden / identity platform metrics (bounded labels):

Platform SLO rules (ops/webx-slo-rules.yaml) also page on durable terminal, verified receipt integrity, and correctness invariants for the broader WebX runtime.

13.3 Tracing

Important spans: request auth → identity compose → proxy acquire → Chrome launch → stealth apply → geo-check → bind context → run loop.

13.4 Alerts

Avoid alerts that only say “CPU > 80%” without user impact.

14. Testing Strategy

Testing pyramid / portfolio

Critical test catalog

Test-source-of-truth rule

Synchronization: UAT contracts assert source tokens and run focused cargo tests; do not re-implement WebX in Python toys.

15. Architecture Alternatives

Option A — Independent knobs (status quo ante)

Advantages: Simple; maximum caller freedom.
Disadvantages: Contradictions; silent trust failures; weak audit.
When it wins: Throwaway scrapes with no login stickiness.

Option B — Unified SessionIdentity composition (chosen)

Advantages: Single source of truth; policy ladder; secret-free evidence; sticky continuity; distance-bounded failover.
Disadvantages: More code paths; operators must configure inventory/geo-check for full value; default permissive still allows weak mode.
When it wins: Logged-in, geo-sensitive, auditable automation (WebX’s market).

Option C — Full probabilistic anti-detect browser farm

Advantages: Marketing appeal.
Disadvantages: Arms race, legal/ToS risk, unprovable claims, huge maintenance.
When it wins: Not aligned with WebX “honest verification” positioning.

Decision matrix

Selected: Option B with policy ladder and explicit non-goals against Option C claims.

16. Decision Log

ADR-001 — Unified SessionIdentity as composition root

ADR-002 — Default policy permissive; coherent/strict opt-in

ADR-003 — Identity distance failover with hard country barrier

ADR-004 — Secret-free context network identity file

ADR-005 — Honest null observed geography

ADR-006 — No probabilistic anti-detect claims in identity modules

17. Implementation Journey

Phase 1 — Fingerprint foundation

Phase 2 — Managed proxy receipts & inventory

Phase 3 — SessionIdentity platform (this branch)

Phase 4 — Operational hardening (ongoing)

18. Product Feedback Loop

19. Rollout Strategy

Feature flag

Related flags: WEBX_FINGERPRINT_PROFILE_JSON, WEBX_PROXY_POOL*, WEBX_PROXY_INVENTORY_*, WEBX_PROXY_GEO_CHECK_URL.

20. Rollback Strategy

Rollback command (illustrative): re-deploy previous webx-server image/tag; restore prior env ConfigMap/Secret; kubectl -n webx rollout undo deploy/webx-api (adjust to live manifests).

Rollback validation: GET /health, GET /ready; create a session without managed proxy; confirm permissive admission; check metrics not stuck failing.

21. Database / Schema Evolution

Identity platform MVP does not require a new SQL table for SessionIdentity; sticky network identity is a file beside the Chromium profile. Durable session catalogue remains in SQLite/Postgres (sessions, logs, etc.).

Prefer expand → observe → contract for any future SQL-backed identity catalogue.

22. Capacity Planning

Current load (qualitative)

Expected growth

Resource bottlenecks

23. Cost Model

Architecture choice: pay for honest managed egress + browser time, not for fake fingerprint entropy.

24. Dependencies

25. Configuration Reference

26. Deployment

Deploy identity platform by shipping webx-server + webx-browser with inventory secrets configured. No separate microservice.

27. Operational Runbook

Symptom: managed proxy 400 unavailable

1. Confirm inventory env/file loaded.
2. Confirm requested geo exists and not all quarantined.
3. Check healthCheckUrl endpoints.
4. Review webx_proxy_geo_mismatch_total and connection failures.
5. Fix inventory; wait quarantine expiry; retry.

Symptom: identity coherence rejection

1. Read error detail (timezone, locale, mobile+desktop, country mismatch).
2. Align WEBX_FINGERPRINT_PROFILE_JSON with requested geo.
3. Or temporarily use permissive only if product accepts weaker guarantees.

Symptom: context reuse continuity failure

1. Ensure second session requests managed proxy compatible with prior snapshot.
2. Inspect contexts/<id>/webx-network-identity.json.
3. If intentional new identity, create a new context id.

Symptom: drift mid-session

1. Check vendor rotation policy vs per_session expectation.
2. Inspect quarantine and failover metrics.
3. Prefer sticky lease hash; avoid multi-country inventory for sticky logins.

Symptom: Chrome major mismatch

1. Align fingerprint browser_version major with pinned browser image.
2. Rebuild/redeploy matching image (Dockerfile.fullchrome / process tier pin).

28. Incident Response

Preserve evidence: session logs, proxy receipts, identity digests, metrics windows.

29. Backup and Recovery

Network identity without profile cookies is incomplete stickiness; restore both.

30. Security Operations

• Rotate proxy inventory credentials via credentialVersion and inventory refresh.
• Rotate API tokens independently.
• Audit that receipts never contain passwords (spot-check session JSON).
• On suspected secret leakage in logs, rotate vendor credentials immediately.

31. Compliance / Audit posture

Does not by itself satisfy industry compliance certifications; it provides evidence primitives.

32. Known Limitations

1. Default permissive allows contradictory identities if callers do not opt into coherent/strict.
2. Timezone/locale plausibility maps are conservative high-value rules, not a complete IANA×ISO database.
3. In-process quarantine state is not a distributed consensus fabric.
4. Context stickiness is filesystem-local unless shared volume / future context v2.
5. Not a bot-bypass product.
6. per_request / on_failure rotation recorded for vendor adapters; static pool treats as per-session semantics.
7. Shared-context orchestrator tier does not materialize on-disk context persistence.

33. Evolution Triggers

Revisit architecture when:

• Multi-worker sticky contexts without shared FS become a GA requirement.
• Product sets coherent as default for all production binds.
• Need hardware attestation or TPMs for browser identity.
• Multi-region sticky egress SLA requires control-plane lease authority.
• Fingerprint schema cannot express required surfaces (e.g., full UA-CH brands list evolution).
• Evidence shows distance weights mis-rank safe failovers.

34. Open Questions

1. When should production default move from permissive → coherent?
2. Should Browserbase session responses expose a public identity provenance object beyond proxy receipt?
3. What is the supported retention for context profiles in paid tiers?
4. Which geo-check providers are blessed for high-assurance strict mode?
5. How should network budgets interact with multi-provider price hints in scheduling?

35. Glossary

36. FAQ (handoff completeness)

37. Source Map (debug index)

38. Change History (implementation)

39. Risks Register

40. Handoff Checklist

A senior engineer can answer:

• What it is and why
• Invariants and policies
• Compose → acquire → launch → observe flow
• Sticky context continuity rules
• Failover distance semantics
• Metrics and UAT IDs
• Config knobs and rollback
• Non-goals (no anti-detect claims)
• When to revisit

If any checkbox fails for a reader, update this record.

41. Quick Reference

# Install / build
cargo build -p webx-server

# Development server
cargo run -p webx-server

# Static checks
cargo fmt --all -- --check
git diff --check -- . ':!combined_project.txt'

# Unit tests (identity-focused)
cargo test -p webx-server --lib detect_drift_flags
cargo test -p webx-server --lib preferred_lease_hash
cargo test -p webx-server --lib identity_preserving_failover
cargo test -p webx-server --lib two_contexts_produce_isolated
cargo test -p webx-server --lib network_budget_without_price
cargo test -p webx-server --lib capacity_is_enforced_at_register
cargo test -p webx-browser --lib stealth

# UAT harness contracts
python3 -m unittest discover -s uat/contracts -v

# Deterministic UAT profile
python3 -m uat.runner --profile local-deterministic

# Production build (image)
docker build -f Dockerfile.fullchrome -t webx-server:local .

# Run task (local)
curl -X POST http://localhost:8081/api/tasks \
  -H "x-api-key: $WEBX_API_KEY" -H "Content-Type: application/json" \
  -d '{"task":"Go to https://example.com and report the main heading."}'

# Managed session (Browserbase-shaped)
curl -X POST https://webx.agentslab.host/v1/sessions \
  -H "X-BB-API-Key: $WEBX_API_KEY" -H "Content-Type: application/json" \
  -d '{"timeout":300,"proxies":[{"type":"webx","geolocation":{"country":"US"}}]}'

# Health
curl -s https://webx.agentslab.host/health
curl -s https://webx.agentslab.host/ready

# Deploy / rollback
# (environment-specific) kubectl -n webx rollout undo deploy/<webx-api>

# Recovery
# Fix WEBX_PROXY_* inventory; release stuck sessions; recreate context if identity file corrupt

Recommended production identity settings (high assurance)

WEBX_IDENTITY_POLICY=coherent   # or strict
WEBX_FINGERPRINT_PROFILE_JSON='{"schema_version":"webx.fingerprint.v1", ...}'
WEBX_PROXY_INVENTORY_FILE=/secrets/proxy-inventory.json
WEBX_PROXY_GEO_CHECK_URL=https://ipinfo.io/json

42. Related Artifacts

43. Document Maintenance Contract

Update this record when there is a material change to:

• product intent or default identity policy
• architecture / composition boundaries
• invariants
• fingerprint or session-identity schema versions
• proxy failover distance policy
• external contracts (/v1/sessions proxy fields)
• security model for identity artifacts
• deployment/rollback for identity flags
• SLOs / metrics names
• UAT-047..054 scope
• known limits or evolution triggers

Do not preserve obsolete instructions merely because they once existed.
Use ADRs and implementation journey for history.
Keep operational instructions describing what works today.

44. Final Engineering Principles

1. Start with the problem — coherent, sticky, provable identity for logged-in automation.
2. Architecture is boundaries and invariants — not a fingerprint JSON alone.
3. Explicit tradeoffs — consistency over availability under coherent/strict; compatibility under permissive.
4. Design failure intentionally — no safe failover is better than a silent country hop.
5. Operability is part of the feature — metrics, quarantine, UAT IDs.
6. Tests protect risks and invariants — UAT-047..054 map to INV-*.
7. Irreversible decisions carefully — schema versions and default policy changes.
8. One canonical source of truth — SessionIdentity composition; UAT IDs in manifest.
9. Measure outcomes after shipping — validation failure and drift rates, not just deploys.
10. Document why — ADRs record rejected anti-detect fantasy.
11. Record mistakes without rewriting history — e.g., never copy prior lease into a fake active lease.
12. Define when to change — multi-worker sticky storage and default policy promotion are explicit triggers.

45. Final System Statement

Session Identity Platform exists to help automation integrators, operators, and logged-in portal workflows accomplish browser sessions whose fingerprint, geography, egress, and sticky context remain coherent, evidence-backed, and fail-closed when integrity cannot be guaranteed. It is implemented using a unified SessionIdentity composition root in webx-server, integrated with ProxyManager acquisition, process-tier Chrome profiles, and FingerprintProfile stealth application, because independent knobs produced silent trust failures and unprovable receipts. The system guarantees secret-free provenance, non-fabricated observed geography, identity-distance-bounded failover, and continuity enforcement under coherent/strict policies, operates within backward-compatible default permissive mode, existing auth, and operator-supplied proxy inventory, and is considered healthy when acquire/validation metrics are stable, UAT-047..054 pass, and high-assurance tenants do not see silent country or fingerprint major drift. Its most significant current risks are permissive-default underuse, filesystem-local sticky contexts in multi-replica deployments, and operator inventory misconfiguration. The architecture should be reconsidered when portable multi-worker context storage or a production default of coherent becomes mandatory. Production ownership belongs to the WebX platform / browser runtime team.

This is a living engineering record. It should contain enough product context, architectural reasoning, operational knowledge, and implementation history for another senior engineer to safely understand, operate, challenge, extend, migrate, or replace the Session Identity Platform within WebX.