Public usefulness
Can projects, methods and decisions be shared, indexed and understood independently?
AcceptedDR-00118 Jul 2026
System architecture · Privacy · Knowledge design
Separate public knowledge from private memory.
KhaiTriOS will publish reusable proof, principles, playbooks and public-safe decisions while credentials, personal memory, client-sensitive information and private AI context remain in a separately protected layer.
01 · Context
The system needs to be discoverable without making sensitive context discoverable.
KhaiTriOS has two different jobs. It should publicly demonstrate how projects are built and how decisions are made, while eventually giving AI assistants richer personal and operational context.
Those jobs require different trust boundaries. Public pages benefit from indexing, links and reusable explanations. Private context may contain credentials, personal memory, client details, account identifiers, raw conversations and assumptions that should never be published.
The architectural decision was required before expanding the public system or building the private AI layer, because mixing both types of knowledge in one location would make every future publication riskier.
02 · Decision criteria
The architecture must maximize usefulness without weakening trust.
Privacy safety
Can credentials, personal data and sensitive operating context remain protected by default?
AI portability
Can approved context later be packaged for multiple assistants without publishing it?
Maintenance clarity
Can a contributor tell where information belongs and which layer is authoritative?
Reversibility
Can the boundary evolve without rewriting or deleting public history?
Trust
Can visitors and collaborators understand what is deliberately excluded?
03 · Options considered
Three architectures were available.
OPTION ARejected
Publish the complete operating system
Place public knowledge, personal memory, credentials and AI context in one repository or website.
- Maximum transparency and one source location.
- Unacceptable disclosure risk.
- Private detail would limit what could safely be recorded.
OPTION BRejected
Keep the complete operating system private
Use one protected vault and publish only the conventional portfolio.
- Strong privacy and low boundary complexity.
- No public knowledge system or reusable proof.
- Projects and lessons remain fragmented for visitors.
OPTION CSelected
Separate public knowledge and private memory
Maintain a public OS for reusable records and a private vault for sensitive context.
- Public usefulness and private depth can grow independently.
- Requires explicit publishing rules and occasional summarization.
- Creates a safe foundation for later AI context packs.
Decision
Use a two-layer architecture with a public knowledge system and a separately protected private memory layer.
The public layer contains only information that can be intentionally shared: operating principles, project records, playbooks, decision records, roadmap and changelog. The private layer will later contain identity context, raw memory, credentials, sensitive decisions, client data and assistant-specific context packs.
Different information needs different defaults
Public knowledge should default to shareable. Private memory should default to protected.
Separation improves honesty
The private layer can preserve useful detail without forcing every note through a public-writing filter.
Public proof remains inspectable
Visitors can evaluate real architecture and reasoning without needing access to private records.
AI context can remain portable
Approved private context can later be packaged for different assistants while the public URLs remain stable.
05 · Consequences
The boundary creates both benefits and operating obligations.
Public work becomes easier to discover
Projects, playbooks and decisions can be indexed, linked and evaluated independently.
Private context can be more complete
Sensitive memory does not need to be weakened into vague public language.
Future AI assistants receive intentional context
Context packs can be assembled by task and tool instead of exposing the complete vault.
Some information needs two representations
A private source may require a public-safe summary before it becomes publishable.
The boundary requires review discipline
New records must be checked for personal data, credentials and commercially sensitive context.
Two repositories increase maintenance
The private vault will need its own structure, history and access controls when implementation begins.
06 · Publishing guardrails
Information crosses the boundary only through explicit transformation.
Shareable by design
- Operating principles and quality standards.
- Project architecture and public-safe outcomes.
- Reusable playbooks and checklists.
- Decision rationale without sensitive inputs.
- Roadmap, changelog and public evidence.
Review before transfer
- Remove credentials and account identifiers.
- Remove personal, guest, lead and client-level data.
- Generalize commercially sensitive detail.
- Confirm the public record remains useful.
- Record what was intentionally excluded.
Protected by default
- Personal identity and long-term memory.
- Credentials, tokens and access details.
- Raw client information and communications.
- Private goals, finances and sensitive decisions.
- Assistant-specific context and internal prompts.
07 · Evidence to date
The public layer has already tested the decision at increasing depth.
Public foundation established
Principles, roadmap, changelog and privacy language were published without private credentials or personal memory.
Four project records published
Scent OS, AGVN, Airbnb Operations and Advertising Dashboards preserve architecture and lessons while excluding sensitive operating data.
Four playbooks published
Reusable methods became public without publishing client identities, private pricing, raw prompts or account details.
The boundary itself becomes traceable
This decision record documents the choice and defines how future evidence can challenge it.
Derived lesson
Later evidence converted this decision into a reusable operating rule.
The decision explains why the layers are separate. LSN-001 explains what future publishing workflows must do to keep that separation effective.
LESSON RECORD 001
Read linked lesson
A privacy boundary must be operational, not rhetorical
Classification, transformation, validation and human ownership turn the architecture decision into repeatable publishing behavior.
08 · Review plan
Review the boundary when AI context begins moving between systems.
Before Phase 05 begins
Confirm the private vault architecture and access model before creating AI context packs.
When a public record needs sensitive context
Test whether summarization preserves enough value or whether the record should remain private.
When multiple assistants use private context
Review permissions, context minimization and update ownership.
When maintenance becomes excessive
Consider tooling or metadata links without merging the trust boundaries.
Decision status
Accepted. Evidence collection continues.
This record remains active until a later decision reverses or supersedes the public/private architecture.