Delivery targets

This records the expanded product direction accepted by the owner. It is a delivery target, not a statement that the capabilities below have shipped. Existing acceptance requirements remain outstanding until replaced by explicit equivalent or stronger tests. Existing receipts do not establish acceptance of this expanded platform.

Product and deployment

Brainlyy is a private-by-default platform for useful, verified work across a person's or small team's knowledge, tools and machines. Marketing and public documentation use https://brainlyy.xyz on Vercel. The application uses https://app.brainlyy.xyz. DNS is managed in Cloudflare. The current application backend is a stateful Python service; a static Vercel deployment cannot replace its relay and storage. Preserve that separation until a tested migration exists.

The owner selected native installation without a terminal, work-and-outcome-first UX, selective modernization, scoped autonomous execution and user-owned always-on workers. Cloud inference is opt-in. No cloud worker or foundation-model training is part of the first release. Graphics means knowledge, code, evidence and execution graphs, rather than an image-generation studio.

Getting started

The finished journey is install, open, optionally sign in, approve discovered sources and complete a useful task. Users need no Python, Node, Docker, JSON editing, copied bearer tokens or shell commands. A signed native application bundles the runtime and manages its lifecycle. Existing CLI usage remains valid.

Detection never grants access. Discovery only proposes local capabilities; approval and operational verification are separate states. Model downloads require consent and expose size, progress, cancellation and recovery. Unsupported hardware or absent models must not prevent local search and inspection.

Remote pairing uses account-bound confirmation and outbound connections. Integrations use provider OAuth where available. Assistant registration is automatic where supported and otherwise guided through the client's UI.

Complete capability target

• Durable tasks, bounded subagents, schedules, budgets, cancellation, checkpoints and recovery on owned workers.
• Real model generation, local retrieval and citation resolution, incremental ingestion, code graphs and evaluator-owned claim verification.
• Supported MCP authorization and streaming, isolated integrations, and versioned Hermes, DeepSeek Harness, Graphify and PAIR adapters.
• Resource-aware multi-machine inference with explicit models, privacy boundaries, health checks, backpressure and bounded failover.
• A dependency-aware work graph connecting sources, claims, checks, runs and deliverables. Changes invalidate affected conclusions and propose or execute permitted repairs without duplicate actions or update loops.
• Reusable workflows proposed from successful work, independently evaluated before promotion, with versioning, regression detection and rollback. Learning cannot expand permissions or alter security policy.

Graph quality includes useful management, detailed provenance, version history, visible access and freshness states, controlled repair review and an accessible list view. The owner explicitly requires a stronger graph experience than Graphify. Treat this as a measured delivery target. Keep the comparison fair: Graphify already supports incremental updates, paths and source references. See managed graphs for the complete requirements and comparison measures. No current superiority claim has been established.

Architecture boundaries

The native shell and web application share a typed frontend. Prebuilt assets ship with the runtime. The Python backend is modular, with separate identity, transport, execution, knowledge and adapter responsibilities.

Hosted persistent storage holds authorized operational metadata. Source content, prompts, answers and execution payloads remain on owning workers by default. Transient relay processing is not end-to-end encryption. Detailed logs, queues, traces and backups must obey the same data boundary.

Execution is durable on the selected worker, not in a gateway process. Uncertain external effects require reconciliation rather than blind replay. Offline source content is unavailable unless its replication to another owned worker was explicitly approved.

Resource authorization is server enforced. Untrusted plugins and generated code need isolation, explicit mounts and network permissions. Missing isolation blocks that execution mode. Publishing, spending, destructive deletion and permission expansion require exact, expiring approval. Credentials are purpose-specific and protected outside user-shareable configuration.

Delivery gates

1. Reconcile contracts and reproduce the baseline.
2. Ship native installation, reviewable discovery and real first-use readiness.
3. Complete identity, remote transport and durable execution.
4. Complete real models, clients, integrations, harnesses and compute routing.
5. Ship dependency-driven verification and evaluated workflow improvement.
6. Complete UX, migration, operations, documentation and independent security review.
7. Measure competitive performance and remediate before general availability.

At least 90 percent of representative first-time users must reach a useful result without assistance or terminal use. Target median first-launch-to-result under five minutes when model download is already satisfied; report download and provider authorization separately.

Evaluate at least 120 held-out coding, research and private-knowledge tasks using pinned competitors, equivalent models, access, hardware and budgets. The target is a ten-percentage-point aggregate improvement over the strongest comparable baseline, with a positive confidence interval and no material category or security regression. Do not claim superiority from design intent.

Qualify 500 machines and 100 concurrent runs in a 72-hour soak. Hosted availability target is 99.9 percent; metadata recovery targets are 15 minutes RPO and one hour RTO. These are targets requiring evidence, not current service commitments.

General availability requires signed artifacts, migration/rollback/restore drills, real OS and assistant-client testing, accessibility review and no unresolved high or critical security findings. Existing fixtures do not replace live evidence.

Initial implementation branch

The first increment introduces native sidecar packaging, a reusable authenticated ASGI application factory, safe discovery/readiness boundaries and desktop-aware release digests. It does not implement the full platform or establish signed distribution, production deployment or competitive performance.