Direct answers. Explicit boundaries.

Black Swan Net is a secure communications program developing dedicated full-Linux endpoint appliances for direct, mutually authenticated sessions between explicitly authorized devices. It is not an app added to a general-purpose phone.

Direct is the stock Pixel 10a reference track and deployable baseline under development. Sovereign is the modified RED/GREEN dual-WLAN high-assurance hardware direction. Gateway extends Sovereign to an authenticated trusted workstation without ordinary Internet access. Assurance is the maintained release, evidence, incident, replacement, logistics and depot lifecycle.

No. The selected production direction is a minimal, immutable and independently controlled full-Linux userspace on the Pixel-derived boot chain. Android and GrapheneOS are obsolete as the production baseline; they may remain only as temporary hardware-discovery or comparison environments.

No. Black Swan Net is in active product development. The public record does not claim general availability, an operational customer deployment, a completed Sovereign/Gateway implementation, or independent proof of the final product.

No. The selected operational baseline is synchronized and direct only. If the recipient is unavailable, an encrypted local draft or pending object may remain on the sender under policy, but nothing is transmitted or deposited with Black Swan infrastructure.

No operational Black Swan message server, queue, cloud message store, identity service, directory, relay, push service or vendor key-custody system participates in the selected session baseline. Parties coordinate availability through operating procedure or another approved out-of-band mechanism.

That absolute claim is not made. Public web hosting, customer systems, software distribution, time, provisioning, evidence or administrative processes may use infrastructure outside the direct content path. The scoped claim is that the operational communications session excludes the listed Black Swan message and identity services.

No. Access networks, endpoints and observers may still learn or infer IP, timing, volume, RF, location, session or relationship information. Direct-only operation removes selected provider dependencies; it does not create zero metadata or anonymity.

In the Sovereign engineering direction, the external access network and separate RED radio are treated as compromisable. Compromise may deny service or expose outer-network metadata, but the design objective is to prevent that compromise from reaching plaintext, identity private keys, fleet secrets or the full-Linux security domain. This objective still requires implementation and independent testing.

No. Radio association and network reachability never establish trust. A GREEN client must satisfy cryptographic identity and policy admission. Unknown or revoked clients receive no useful session service.

The device is removed from operations, its identity is permanently revoked, applicable fleet state advances, and a replacement can be provisioned. Returned hardware enters controlled quarantine, depot analysis, complete reconstitution or destruction according to customer policy.

No. The compromised or suspect identity is never restored. Hardware may receive an entirely new identity only if the assurance policy permits reconstitution and the device passes the required inspection, sanitization, firmware, boot, diagnostic and recertification gates.

A recurring lifecycle offering that can include controlled signed releases, vulnerability response, fleet and policy renewal, incident response, replacement service, secure depot handling, configuration control, security advisories, evidence maintenance, spare pools and priority response options.

The four public paths are a private demonstration, an enterprise pilot, a government briefing and an integration-partner discussion. Government paths may lead to a paid design study, controlled technical evaluation, unclassified/CUI pilot or sponsor-defined high-assurance program.

Not in this release. Available device and annual-Assurance ranges remain planning hypotheses, not approved public offers. Pricing depends on exact hardware, policy, evidence, secure logistics, support, replacement and deployment scope.

Only an unclassified, non-sensitive mission category, sector, approximate fleet size and desired timing. Do not submit classified, CUI, export-controlled, privileged, case-specific, security-sensitive, credential, vulnerability, source-identity, evidence or operational information.

No. It is not currently represented as certified, government-approved, authorized for CUI or classified information, or equivalent to a SCIF.

Component validation applies to a defined component and scope. Product evaluation applies to a specified product version and configuration. System assessment examines the assembled system and operating boundary. Customer authorization—such as an ATO—is a decision by the responsible customer authority for the exact mission and deployment. These are not interchangeable.

They may inform evidence planning for a specific customer or configuration. Their mention does not claim validation, certification, compliance, inclusion on a government list, or authorization. Applicability must be established for the exact system.

No clearance conclusion is stated. A reported prior Ohio emergency-network use is only a diligence lead. Formal USPTO, common-law, domain, category and confusion analysis by trademark counsel remains an open workstream.

No. Patent status does not prove security, product performance, claim scope, freedom to operate or trademark rights. Security engineering takes precedence over preserving an earlier provisional-filing architecture.