The public host split for the live product surfaces.

Domain model

• owlyvision.com is the canonical Product Brief public surface.
• owly.vision is the Launch Check and paid Launch Report public surface.
• app.owlyvision.com is the private runtime for briefs, reports, APIs, share links, and exports.
• docs.owlyvision.com is the documentation surface.

Runtime shape

The app surface runs on a live application runtime, while the docs surface lives on a separate static Hostinger subdomain so documentation delivery stays decoupled from the product runtime.

• The app host needs a long-running runtime, healthchecks, and persistent state.
• The docs host is static in content and fits well on a Hostinger-managed subdomain with platform SSL.
• The marketing apex can stay separate so legacy redirects and SEO control remain deliberate.
• A desktop or Tailscale bridge can still be useful for internal experiments if the analysis worker lives on a private host, but that is a bridge path, not the canonical public app host.

Analysis provider model

Submitted URLs are processed server-side on the app surface. The browser creates a persistent brief job, polls job status, and redirects only after the server has persisted the finished brief.

• The default public processor path is deterministic and does not expose provider credentials.
• The current command-adapter seam can route evidence to GPT, Opus, Gemini, Acer, or another worker behind the API.
• Longer production model calls should run from a separate worker process using the brief job queue.
• Provider routing must remain server-side; model keys, SSH access, and worker details should never be exposed to the browser.
• Use python scripts/smoke_test_analysis_adapter.py before pointing the live app at a new adapter command.
• The current verified public path is a direct Quatarly HTTP adapter on the app host. Private Acer/Tailscale workers are still useful, but they should be treated as bridge or internal lanes instead of the default public runtime dependency.
• Tailscale Funnel is useful for short-lived demos, but it currently publishes only a Tailscale hostname rather than the canonical app.owlyvision.com domain.

App access model

The app currently uses named workspace access codes with owner, operator, and viewer roles. Owner and operator codes can change workspace data; viewer codes can inspect briefs without write access.

• Use OWLYVISION_APP_ACCESS_TOKENS_JSON for production workspace accounts.
• Use python scripts/generate_app_access_tokens.py to mint named owner/operator/viewer accounts instead of hand-writing the JSON payload.
• The legacy single-token variable remains available only as a compatibility fallback.
• Public share links remain token-based and do not require an app access token.

Indexing and canonical ownership

• Marketing pages canonically belong to owlyvision.com.
• Docs pages canonically belong to docs.owlyvision.com.
• Private app/share surfaces should stay noindex.
• The docs surface should have its own robots and sitemap behavior rather than inheriting marketing rules.

Legacy path preservation

OwlyVision still carries legacy outbound-preview traffic from the earlier automation system. Because of that, apex changes must preserve the redirect paths that were explicitly moved elsewhere rather than treating the root domain as a blank slate.

Practical operating rule