Internal prior art: HALO model surfaces and Oracle Streaming crossover

Date: 2026-08-29

Status: bounded read-only evidence note for the OFM domain owners.

Evidence boundary

• clients/halocrm/repo/ is Camron's private live clone and was read only.
• apps/oracle-streaming/ is active and protected. Only current on-ramps and bounded

product evidence were read; no file was changed, no credential was accessed, and no operational or live-account command was run.

• Serena's local daemon was unavailable (ECONNREFUSED 127.0.0.1:24225) and native Serena

was not exposed, so HALO inspection was restricted to the known route file, known gamification page, and existing verified research rather than a broad code grep.

Oracle Streaming product evidence

The current Oracle on-ramp defines the creator/model job as:

one action starts a multi-platform live workflow; viewer chat and tips flow into one cockpit; real events drive goals/overlays; state persists to Convex.

Current proof documentation records:

• a one-press multi-platform go-live path;
• real viewer chat and tip ingestion into Convex;
• deduplication of platform events;
• a goal bar advanced from approved tip truth rather than decorative data;
• goal and tip-alert overlays;
• model-facing camera/microphone setup and a go-live wizard;
• explicit human-present/account-safety gates and per-platform evidence.

Authoritative routes consulted:

• /Users/shaansisodia/SISO_Workspace/SISO_Agency/apps/oracle-streaming/AGENTS.md
• /Users/shaansisodia/SISO_Workspace/SISO_Agency/apps/oracle-streaming/CLAUDE.md
• /Users/shaansisodia/SISO_Workspace/SISO_Agency/apps/oracle-streaming/docs/PROVEN-LEDGER.html

Do not infer the runtime from the old root README: AGENTS.md says the current Mac worker is the Rust/Tauri binary, while Electron remains valid only for the explicitly VPS-owned engine/browser shell.

HALO surfaces already visible

The known route map contains internal creator directory/profile/analytics/invoice routes; tokenized onboarding and contract-signing routes; a creator upload route; Shared Drive; AI voice; and a substantial Tasks & Rewards application.

The Tasks & Rewards page already composes:

• a game board;
• quests and a chatter-quests surface;
• a supply depot/shop;
• player cards;
• a manager control panel;
• player versus manager navigation and participation rules.

Existing verified research measures the domain at about 7,599 LOC and records two append-only currencies (XP and bananas), shift/day-scoped quests, completion evidence, re-rolls, purchases, ranks and leaderboards. The canonical count is 14 gamification tables; older lane reports used 13 or 17 and should not override CANONICAL-NUMBERS.md.

This is meaningful product prior art. The training/gamification lane must start by mapping what is already built, then supply the missing measurement, simulation, coaching and creator-engagement layers.

The visible route map alone does not prove or disprove Camron's claimed dedicated model-facing app. Public/tokenized onboarding, upload and signing surfaces are not the same thing as a complete creator portal. Treat the claim as open until the creator lane locates the actual surface, repository, deployment or product evidence.

High-value crossover hypotheses to test

These are hypotheses for the lanes to test, not implementation decisions:

1. One-action creator operations. Oracle's low-cognitive-load “press once” philosophy

could transfer to creator onboarding progress, content submission, approval, shift availability and request fulfillment.

1. One event vocabulary. Platform chat/tip/content events could share typed IDs,

provenance, deduplication and timestamps without forcing streaming and agency systems into one datastore.

1. Goals grounded in truth. Oracle's real-tip goal and HALO's quest/XP ledgers suggest

a common rule: achievements must derive from authoritative events, never decorative or client-supplied counters.

1. Creator-visible progress. A creator/model app could show transparent onboarding,

content, approvals, availability, requests, statements and goals while protecting internal chatter discussion and staff controls.

1. Live-to-agency continuity. Streaming chat/tips, OnlyFans sales/customs, content

production and payouts may all contribute to one creator relationship timeline while retaining separate state machines and platform authority.

1. Shared media and identity controls. Camera/mic setup, likeness/voice consent,

content rights, account access, and creator boundaries need compatible evidence and revocation semantics even when products remain separate.

1. Human-readable proof. Oracle's proof-ledger discipline is relevant to HALO's money,

approvals, access and agent actions: a status without source evidence should not drive a consequential reward or mutation.

Non-transferable boundaries

• Streaming go-live transport, OBS, OME, browser/readback and platform connector details

are specific to Oracle unless a HALO workflow explicitly consumes their safe events.

• Live chat/tip capture does not automatically become OnlyFans messaging capability or

permission to automate creator impersonation.

• A shared Convex vendor does not imply shared deployment, auth, schema or trust boundary.
• Gamification cannot substitute for QA, fair compensation, consent, creator autonomy,

wellbeing or server authorization.

• Oracle's account-safety and human-present rules must not be weakened to make an OFM

automation demo look more complete.

Questions every relevant lane should answer

• Is the model app a HALO route, separate repository, deployment, prototype or claimed

plan? What exact personas and authority does it implement?

• Which model-facing tasks need immediate/real-time UX versus a portal/inbox?
• Which authoritative events may drive creator or chatter goals and which must never do so?
• Can Oracle events be linked through stable external IDs without cross-product data

duplication?

• What does the creator control, approve, export and revoke?
• What survives staff turnover, account suspension, platform outage or agency exit?