Platform Capabilities
Próx OS uses user-facing app collections to explain product value, and platform capabilities to keep the architecture reusable.
Próx OS uses user-facing app collections to explain product value, and platform capabilities to keep the architecture reusable.
App collections are for users and the market. Platform capabilities are for architecture, APIs, permissions, and the developer ecosystem. The App Store shows app collections; architecture docs and developer docs should expose capability APIs over time.
The 8 Platform Layers
| Platform | Purpose | Core Objects / Capabilities |
|---|---|---|
| Source Platform | Manages external and future local sources such as GitHub, RSS, Cloudflare, Neon, Notion, Airtable, Google Drive, Obsidian, Eagle, and local folders. | Source, Connector, Credential, Sync Status, Permission |
| Information Platform | Turns external information into structured objects. | Article, Repo, Tool, Project, Person, Company, Paper, Video, Dataset |
| Knowledge Platform | Turns information into long-term knowledge. | Tags, summaries, bookmarks, comparisons, citations, knowledge graph, AI memory |
| Workflow Platform | Turns information into action. | Reminders, auto-classification, generated issues, webhooks, n8n handoffs, agent workflows |
| Permission Platform | Decides who and which app or AI can access what. | App permissions, AI permissions, public/private visibility, read/write scope, local/cloud scope |
| View Platform | Lets the same data appear through different interfaces. | Tables, kanban boards, timelines, graphs, maps, calendars, desktop windows, dashboards |
| Publishing Platform | Publishes internal data outward. | Personal home, public Space, project showcase, RSS feed, API, embedded component |
| App Runtime Platform | Lets official and third-party apps build on Próx OS capabilities. | App manifest, Window API, Data Source API, Permission API, AI Context API, Theme API, Storage API |
Capability Boundaries
- Source Platform owns connection metadata and sync state. It does not decide how a radar, inbox, or dashboard renders.
- Information Platform creates structured records from source payloads. It should keep provenance back to the source.
- Knowledge Platform stores durable meaning: tags, summaries, references, comparison notes, and memory candidates.
- Workflow Platform converts data into actions, but permissions must gate side effects.
- Permission Platform must be visible to users and enforceable by API and runtime layers.
- View Platform should support multiple projections of the same object set rather than one app-specific shape per UI.
- Publishing Platform controls what leaves the private OS and becomes public, embeddable, API-readable, or cloneable.
- App Runtime Platform is the developer surface that connects manifests, windows, permissions, data sources, AI context, themes, and storage.
Near-term Bias
The first platform work should support cloud-first source ingestion and view reuse for Awesome GitHub Radar, RSS Knowledge Inbox, GitHub Workspace, and AI Context Builder. Local bridge and broad personal archive ingestion remain later capabilities.