Source truth
Open-source concept
ChipOS is being shaped in public through its docs, install contract, model pages, wrapper pages, and controlled contribution path instead of staying only a private internal story.
Open Source / GitHub
Open-source docs and GitHub for a self-hosted AI platform.
ChipOS is an open-source owned AI control layer and self-hosted platform project we are already using across our own apps, websites, and operating flows. The website is the clearest public documentation and intake surface today. The main ChipOS repo is the outward public record for the product, while the website repo stays separate for chipos.io itself.
Current truth
ChipOS is not only an idea. It is already in use, and it is still early.
The honest reading is simple: ChipOS is a real open-source concept with real internal use already behind it, but the public source surface is still maturing. That is why this page should tell people exactly what is public now, what is already being used, and what is still being hardened.
Source truth
Already used by us
This is not only a future promise. We are already applying this model across our own apps, websites, and operating flows, which is why the concept has real shape today.
Source truth
Still maturing in public
The public source surface is still early. Broader publication, proof surfaces, and repository depth should expand carefully instead of being overstated before they are actually ready.
Source truth
What GitHub means today
The main ChipOS GitHub repo is the outward public record for the runtime, install path, and prompts. The website repo is separate and only covers chipos.io itself. The live website still carries the clearest product story, install truth, and contribution intake today.
Why this is open source
If the system gets stronger from your work, that value should stay with you.
The goal is not to rebuild every outside service from zero. The goal is to keep the owned system, memory, and workflow logic in your environment while still using outside tools when they are useful. Open source matters because that owned layer should stay inspectable, portable, and improvable.
Open source reason
Own the foundation
The core system should belong to the person or team using it, not only to the platform used to compute parts of the work.
Open source reason
Keep the memory
Workflow memory, operating history, and reusable capability should not disappear into a closed product you cannot inspect or carry forward.
Open source reason
Choose how you compute
You can use outside models and coding tools when they help, but they should be leverage for your system, not the permanent owner of it.
Open source reason
Review what is real
Open source lets people inspect what already exists instead of relying on product claims with no public surface behind them.
Public surfaces
Put the real public entry points in one place.
A first-time visitor should be able to open the real public docs, the live intake path, and the current GitHub surface without falling into dead-end repository links or unpublished document paths.
ChipOS repository
Open the public ChipOS repo itself: this is the public GitHub record for the actual runtime, installer, and deployment docs.
Website repository
Open the website repo when you want the source for chipos.io itself, separate from the actual ChipOS runtime and install repository.
README
Start with the public ChipOS README when you want the first code-facing orientation directly inside GitHub.
Install contract
Open the public ChipOS install contract and the current install assumptions directly in the runtime repo.
Deployment contract
Read the public deployment contract that defines how the current ChipOS deployment path is supposed to behave.
Deployment channels
Open the runtime repo document that explains the available install and deployment branches and where each one fits.
Install flow
Use the public install-flow document when you want the step-by-step install sequence from the actual ChipOS repo.
Supported environments
Open the public supported-environments document when you want the current install and runtime boundary in plain terms.
Infrastructure page source
Open the source file behind the Infrastructure page and the stability-layer explanation for why ChipOS does not collapse like raw AI workflows.
Use Cases page source
Open the source file behind the Use Cases page and the connect-before-rebuilding logic.
Contribution policy
Read the public ChipOS contribution policy so the repo review model stays aligned with the public docs and install truth.
Security policy
Use the public security policy for responsible reporting and security-boundary expectations.
Install prompt
Open the public install prompt in the ChipOS repo when you want the current agent-facing installation instruction.
Install from reference
Use the public install-from-reference prompt when you want the install agent to follow the repo docs as the source of truth.
Workspace from reference
Open the reference workspace implementation prompt when you want the UI path to follow the ChipOS repo guidance.
Start here
Route people to the right public documents first.
These are the public documents that actually exist today and make the product legible before someone disappears into missing repository links or half-published source references.
Vision
Read the current public product definition that is actually reachable on chipos.io.
Model
Read the public doctrine, anchored loop, and current operational truth boundary.
Chip Wrapper
Inspect the public system-mapping page for identity, consent, routing, and return.
Architecture
Inspect the public architecture page for deployment sequence and system layers.
Use Cases
Read the use-case library and the truth note about direction versus shipped built-ins.
Infrastructure
Read why ChipOS uses layers, state, boundaries, and verification instead of trusting raw AI workflows directly.
Site and source roles
Let the website explain what is real today.
ChipOS.io should explain why the system exists, carry the public install contract, hold the public model pages, and accept controlled change requests. GitHub should stay close to that public story. Wider source and review surfaces should only be linked publicly once they are actually reachable.
Surface
Product site
Explain what ChipOS is, what is already real today, and where the truth boundary still is without forcing every visitor into raw source first.
Surface
Public docs pages
Carry the Vision, Model, Wrapper, Architecture, Infrastructure, Use Cases, governance, and contact paths on the live site so the public story is actually reachable and inspectable.
Surface
GitHub record
Use the ChipOS GitHub repo as the outward public record for the product while keeping it aligned with the public docs instead of pretending the whole source surface is already broader than it is.
Surface
Website repo
Keep the website repo separate so the public site, layout, and documentation surface can evolve without pretending it is the same codebase as the ChipOS runtime and install system.
Surface
Source expansion
Expand repository, release, and review surfaces only when they are publicly reachable instead of promising proof that a first-time visitor cannot open.
Source map
Curate the important entry points instead of dumping the whole repo on first contact.
A good public source surface points people to the current Vision, Model, Wrapper, Architecture, and Use Cases pages that already exist.
Vision
Start with the Vision page to understand what ChipOS is trying to make possible and what people actually get first.
Architecture
Use the Architecture page to understand the deployment sequence, runtime layers, and owner handoff path.
Infrastructure
Read the Infrastructure page to understand why raw AI workflows collapse and how ChipOS creates stability through layers, state, boundaries, and feedback.
Model
Read the Model page to understand the doctrine, the anchors, and the current truth boundary between philosophy and implementation.
Chip Wrapper
Use the Wrapper page to understand how identity, policy, consent, lanes, residue, and return are meant to become operational.
Use Cases
Read the Use Cases page to see why people want an owned system, where the product is headed, and which parts are still direction rather than finished built-ins.
Deployment sequence
The public logic still needs to stay visible.
People should be able to understand the supported deployment and runtime sequence before they read code or assume ChipOS already supports a path that it does not.
01
Start by choosing the real environment: local computer, cloud host, or your own server.
02
Choose the install prompt that matches reality: local computer for preview, or own-server for any real hosted target you control.
03
If you need a human guide instead, move into operator handoff rather than improvising on the wrong machine.
04
If the selected branch does not match the current machine, the flow pauses and asks for the real target.
05
The agent audits the real environment, prepares the secure foundation, and installs the protected Chip base.
06
The agent publishes owner access, verifies browser reachability, and hands you into Chip.
07
You continue inside the live system while ChipOS keeps setting up memory, workflows, and reusable capability.
Next step
Use the site for orientation. Use the right repo for the right surface.
The website explains ChipOS and accepts public intake. The ChipOS repo holds the runtime and install record. The website repo holds chipos.io itself.