The public product map for a user-controlled computing ecosystem.
Understand the applications, trust boundaries, automation model, native formats, and direction of Vakend—without exposing its private implementation.
51 Applications · System Map · Trust Model · Current Inventory · Formats & Protocols
Vakend Technology Corp. is building a computing environment in which a person can manage identity, private data, communication, artificial intelligence, learning, finance, devices, software, and creative work under one set of rules.
Vakend is not simply a bundle of desktop applications. The applications are intended to cooperate without receiving unrestricted access to one another. Local intelligence may prepare work; trusted devices may exchange approved information; external services may be used when the user chooses them. Identity, permission, and an intelligible record of what happened tie those activities together.
One principle governs the design:
The system may become more capable without making the user less sovereign.
This repository is the public account of that design. It explains what each product is for, how the products relate, what is available now, and what remains experimental. It is written for customers, partners, researchers, developers, and prospective employees. Production source code, security-sensitive mechanisms, and operating infrastructure remain private.
Modern digital work is fragmented across accounts, clouds, applications, assistants, and devices. That fragmentation creates four recurring problems:
| Problem | Vakend direction |
|---|---|
| Personal information is scattered across providers | A user-controlled identity, encrypted vault, and portable cognitive layer |
| Apps operate as disconnected silos | Explicit, capability-scoped application connections |
| Automation often receives excessive authority | Proposal, approval, execution, and audit as separate steps |
| Security claims are difficult to evaluate | Visible trust boundaries, maturity labels, recovery, and reviewable evidence |
Vakend does not claim that every task can or should happen offline. The more useful promise is narrower: the user should be able to tell what happens locally, what leaves the device, which identity authorized it, which application requested it, and whether the action can be revoked or recovered.
flowchart LR
Intent["1 · Human intent"] --> Context["2 · User-approved context"]
Context --> Plan["3 · Local plan or suggestion"]
Plan --> Review["4 · Consequence review"]
Review --> Capability["5 · Narrow capability"]
Capability --> Action["6 · Local, peer, or external action"]
Action --> Evidence["7 · Result, receipt, or audit"]
Evidence --> Intent
Reading is not writing. Suggesting is not executing. Preparing is not sending. Signing is not publishing. Connecting is not trusting.
These distinctions make automation governable. They allow an application to help with a task without assuming every permission that the completed task might eventually require.
flowchart TB
Person["Person"] --> Experience["Applications & visible approvals"]
Experience --> Policy["Identity · consent · capability policy"]
Policy --> Local["Local foundation"]
Policy --> Peer["Trusted peer network"]
Policy --> External["Optional external services"]
Local --> Vault["Encrypted vault & recovery"]
Local --> Intelligence["Local intelligence & portable memory"]
Local --> Devices["Device and native compute services"]
Peer --> Collaboration["Communication · sessions · federation"]
External --> Providers["Mail · market · publishing · optional QPU"]
Vault --> Assurance["Security · governance · runtime · QA"]
Intelligence --> Assurance
Collaboration --> Assurance
Providers --> Assurance
Assurance --> Person
This diagram assigns responsibility; it does not reveal the private software architecture. A line means that two areas may cooperate in an approved workflow. It does not mean that either side can inspect the other freely.
The current public inventory contains 51 application entries, each with a dedicated page, connection diagram, user benefit, automation role, maturity label, evolution table, and disclosure boundary.
| Product family | Representative applications | Strategic role |
|---|---|---|
| Identity & platform | Identity Center, Settings, Runtime Center, Recovery Center | Establish identity, device state, application execution, and recovery |
| Intelligence & automation | Intelligence Center, Agent Studio, Agent Tasks, Brain Manager, Memory Explorer | Use approved context to prepare work that a person can examine |
| Personal workspace | Files, Notes Pro, Calendar, Mail, Contacts, Gallery, Books | Keep everyday digital work inside a coherent environment |
| Communication & network | Chat, Sessions, Network, Connect Devices, Federation Center, Peer Whiteboard | Connect trusted people and devices across explicit boundaries |
| Trust & assurance | Security Center, Trust Center, Governance, Vault Backup, QA Command Center, WhiteHat | Expose risk, policy, testing, recovery, and operational evidence |
| Finance | Wallet, VTrade, Token Administration, Credit Repair | Support deliberate financial workflows with separated authority |
| Learning & research | i7 School, Quantum Lab, Infoton, CTE5:4 Lab | Explore learning, simulation, and research with honest maturity labels |
| Creation & distribution | Developer Studio, Development Center, Vakend Bazaar, VK Game Engine, Wallpaper Store | Move reviewed work from creation toward controlled distribution |
| Devices & utilities | Connect Camera, Shutter, TV Controller, Calculator, Cloud Watch | Bring local hardware and focused tools into approved workflows |
Explore the complete application tree →
Vakend’s public trust contract has five parts:
- User authority — consequential actions require an appropriate level of user awareness or approval.
- Minimum authority — an application or automated task should receive only the access needed for the work at hand.
- Local-first handling — private work should remain local or encrypted unless a selected workflow requires a named connection.
- Visible boundaries — peer and external activity should be distinguishable from local behavior.
- Recoverable systems — backups, revocation, audit history, and failure states are product responsibilities.
flowchart LR
Claim["Product claim"] --> Scope["Named scope"]
Scope --> Evidence["Versioned evidence"]
Evidence --> Choice["Informed choice"]
Choice --> Action["Scoped action"]
Action --> Record["Reviewable result"]
Record --> Correction["Correction when facts change"]
This repository makes the product easier to question. It does not, by itself, prove the security of closed-source software. Such proof requires evidence tied to a particular release: testing, signed artifacts, independent review where appropriate, incident records, and reproducible behavior. See the full Trust Model and Disclosure Boundary.
Vakend uses Internet AI as a name for artificial intelligence that can assist across applications, trusted devices, and selected services while remaining answerable to the user. It is not an agent with unlimited authority, and it is not a concealed pool of everyone’s data.
A user states a goal. Local software gathers permitted context and prepares a plan. If the plan requires a consequential act—sending a message, publishing a file, moving money, or contacting a remote service—the system presents that step for review. The responsible application then receives limited authority to carry it out. The user receives the result and a record of the action.
Potential outcomes include:
- preparing a day across calendar, tasks, mail, and selected documents;
- adapting learning from evidence of mastery;
- coordinating encrypted backup across trusted devices;
- preparing software or content for validation and publishing;
- monitoring defined conditions without silently expanding authority.
Vakend separates quantum work into three honest categories:
| Scope | What it means |
|---|---|
| Learning and simulation | Build circuits and run an ideal state-vector simulation within practical hardware limits |
| Optional physical QPU access | Submit a user-approved job through the user’s own supported provider account |
| Quantum readiness | Inventory cryptographic dependencies and prepare for future post-quantum migration |
A simulator is not a physical quantum computer. A physical QPU does not automatically create practical advantage. A readiness inventory is not a completed cryptographic migration. Research environments are not proof of scientific or medical claims.
Read the quantum computing guide →
| Term | Meaning | Trust note |
|---|---|---|
.vka |
Bundled Vakend visual asset | Obfuscated packaging—not encryption and never a container for user secrets |
.vk |
Recipient-bound encrypted transfer | Sensitive even while encrypted; import through Vakend |
.vkid |
Identity export and recovery artifact | High-value private backup |
.vkbrain |
Portable personal intelligence export | Encrypted personal data, separate from marketplace content |
.vkmp |
Signed distributable package | Signature establishes provenance, not universal safety |
name.vk |
Human-readable Vakend Network name | A signed name record, not a .vk transfer file |
vk:// / vks:// |
Vakend Browser address forms | Subject to Vakend resolution, origin, and trust rules |
Read the complete formats and safe-handling guide →
Vakend organizes work into several families of phases. P70 names the platform-lock checkpoint, when a defined baseline was approved for subsequent development under change control. It does not mean that development ended, that the product became flawless, or that an unnamed outside institution certified every capability.
flowchart LR
Discover["Discover"] --> Build["Build"]
Build --> Connect["Integrate"]
Connect --> Assure["Test & harden"]
Assure --> P70["P70 · governed baseline"]
P70 --> Extend["Controlled extension"]
Extend --> Audit["Audit · correct · repeat"]
Quantum work uses Q-series phases. Other numbered phases cover architecture, security, interface design, performance, marketplace work, models, and release preparation. “RC” means release candidate: a build receiving final review, not a permanent guarantee that defects cannot exist.
Understand P70 and the phase model →
Every public capability should be read with its label:
| Label | Interpretation |
|---|---|
| Current application | Present in the dated application inventory; availability can still vary by release and platform |
| Early public capability | A real but still-evolving product surface, commonly reflected by a 0.x inventory version |
| Optional integration | Disabled or unused unless the user deliberately configures and authorizes it |
| Research | Exploratory work that must not be represented as production proof |
| Future direction | A product intention, not a shipped promise |
The inventory snapshot is dated July 26, 2026. Start with Application Updates, then open the individual application page for its diagram and trust contract.
CommunityOpenView/
├── README.md Company and ecosystem overview
├── data/apps.json Dated public application inventory
├── docs/
│ ├── apps/ One guide and diagram for every application
│ ├── concepts/ Internet AI, quantum, and native formats
│ ├── history/ P70, phases, versions, and updates
│ ├── trust/ Trust model and disclosure boundary
│ └── system-map.md Whole-system responsibility map
├── assets/ Public documentation artwork
├── scripts/ Documentation generation and validation
├── CONTRIBUTING.md How to suggest corrections
├── SECURITY.md Private-reporting guidance
├── TRADEMARKS.md Brand-use boundary
├── NOTICE Copyright and proprietary-technology notice
└── LICENSE Apache License 2.0 for repository contents
Application pages are generated from the dated inventory. The repository’s validation workflow checks that every inventory entry has a page and Mermaid diagram and that generated content has not drifted.
node scripts/generate-app-pages.mjs
node scripts/validate-docs.mjs
git diff --exit-codeThese checks show that the inventory, pages, and diagrams agree with one another. They say nothing about the security of a production release or whether a feature is available on a particular device.
Useful contributions include:
- correcting an inaccurate or outdated product statement;
- asking for a clearer trust boundary or limitation;
- improving a diagram, definition, or accessibility;
- proposing public evidence that would make a claim more verifiable;
- identifying language that confuses research, roadmap, optional integration, and current capability.
Read CONTRIBUTING.md. Do not publish credentials, private source, personal data, or unpatched vulnerability details. Security-sensitive reports belong in the private channel described in SECURITY.md.
Copyright © 2026 Vakend Technology Corp. Repository content is provided under the Apache License 2.0. That license applies only to the material actually published here. It does not grant access to or rights in Vakend’s private source code, models, production systems, confidential information, patents not licensed by the license’s terms, or other unpublished technology.
“Vakend,” “Vakend OS,” “VKBrain,” product names, logos, and related source identifiers are trademarks or brand assets of Vakend Technology Corp. The Apache License does not grant permission to use them except as required for reasonable attribution. See TRADEMARKS.md and NOTICE.
Nothing in this repository is investment, legal, financial, medical, or security advice; an offer to sell securities; a warranty; or a guarantee of roadmap delivery, valuation, availability, regulatory status, or fitness for a particular use.
This repository is designed to become more accurate through specific, reviewable corrections. If a statement is unclear, overly broad, or out of date, open an issue identifying the page, exact language, proposed correction, and public evidence where available.
For corporate partnerships, licensing, security reporting, press, or formal verification requests, use an official contact channel published by Vakend Technology Corp. Do not rely on an address copied into an issue or submitted by an unverified third party.
Understand the system. Challenge the claims. Keep the user in control.