Summary
Closed Akashic should split internal memory into at least two scopes: per-user private memory and shared-but-private team memory. Shared memory should not be written directly by arbitrary clients; a server-side LLM or controlled promotion pipeline should decide what enters shared space.
Findings
- The current product intent already separates Open and Closed instead of merging them.
- Closed Akashic already distinguishes
sharedandpersonalfolders, but this is a content convention, not a user-aware access model. - Closed Akashic currently uses one bearer token and one vault root, so it is effectively a single trust domain.
- Open Akashic already fits a server-side promotion model because writes are controlled and accepted claims require evidence.
- An LLM-maintained wiki loop fits Closed Akashic well if it is bounded by queue, scope, and review rules.
Recommendation
- Keep Open and Closed separate.
- Inside Closed, treat
scopeas a folder/context hint, not as an access-control field. - Use
owner,visibility, andpublication_statusas the explicit governance fields. - Keep user drafts, opinions, and raw reflections private by default.
- Run a periodic librarian job that only updates targeted note sets, records provenance, and never rewrites beyond a configured budget.
Clarification
If the product goal is one MCP endpoint, prefer one control plane over one undifferentiated store. A single authenticated MCP can expose both note-style private memory and public claim/evidence memory, while the backend still keeps separate schemas, visibility policies, and promotion rules.
Product Direction
The stronger product shape is not "everyone reads the raw knowledge base" but "vetted source corpus in, publishable know-how out".
- Store validated source materials such as wiki-style evidence notes, experiments, reproductions, theories, papers, datasets, images, and files behind access control.
- Let agents and server-side jobs use that source layer to derive public claims, evidence summaries, capsules, and practical know-how.
- Let general users mainly receive the publishable result layer, not the full raw source layer.
- Keep provenance from public outputs back to internal source objects, while exposing only what the policy allows.
Librarian Agent
Non-public data can remain user-editable like the current Closed Akashic flow, while publication-related handling is owned by a server-side librarian agent.
- Users and local agents should freely manage private drafts, notes, source files, and internal working memory.
- The librarian agent should own publication review, promotion to shared/public layers, backlinking, deduplication, and bounded restructuring.
- The librarian agent can store its operating prompt, persona, allowed skills, tool access policy, and reusable playbooks inside the same system as explicit governed documents.
- Prefer storing the librarian's durable configuration and policy memory, not every transient chain-of-thought or chat trace.
- Separate
agent profile,agent policy,agent playbooks,agent memory, andagent activity logso long-term behavior stays auditable. - Let the librarian read broad source material, but only write into shared/public zones through policy-constrained workflows.
Ownership And Publication Metadata
Every document should carry explicit governance metadata.
owner: the accountable nickname or agent identity. Current bootstrap identities areaaronfor the master-token admin andsagwanfor the librarian manager.visibility: defaults toprivate; valid values are onlyprivateandpublic.publication_status: defaults tonone; publication flow usesrequested,reviewing,approved,rejected, andpublished.scope: optional folder/context helper such assharedfor common knowledge/opinion andpersonalfor personal information/opinion; it should not duplicate the permission model.- MCP/API note writes are private personal storage by default, not public publishing.
- Public exposure starts only through a publication request owned by the server-side librarian workflow.
owneris immutable through normal editing. It is bound to the creating user's nickname/token identity.- When a note becomes public, stewardship moves to
owner=sagwanwhile the source author remains inoriginal_ownerandcreated_by. - Private notes are readable and editable only by their owner and admins.
- Public notes are readable as public artifacts, but only admins/managers may add, modify, delete, move, or merge them.
- Normal users may only edit their own notes and set publication status to
noneorrequested; admins/managers decidereviewing,approved,rejected, andpublished.
MCP Flow
The unified MCP should expose one control plane while keeping storage policy explicit.
upsert_note: saves private/personal notes by default.request_note_publication: creates a librarian review request and marks the source note as requested.list_note_publication_requests: lets the librarian or admin review pending publication requests.set_note_publication_status: lets the librarian or admin record decisions;publishedalso makes the sourcevisibility=public.- Public-facing tools should read only
publicderived artifacts unless an authenticated policy grants broader source access.
Reuse
Prefer a three-step flow: private capture, librarian review, public promotion to Open Akashic.
Sagwan Revalidation 2026-04-15T06:51:26Z
- verdict:
ok - note: scope/governance field 권장안은 기본 원칙으로 현재도 유효하며 참고 가치 있음.
Sagwan Revalidation 2026-04-15T07:09:32Z
- verdict:
ok - note: 권장안(visibility/owner 필드기반 거버넌스)이 현재 MCP 구현과 CLAUDE.md 규칙에 반영되어 유효하고, 2026-04-15 검증 이후 변동 없음.
Sagwan Revalidation 2026-04-16T07:11:24Z
- verdict:
ok - note: 설계 권장안이며 1일 경과, MCP/토큰 기술 기초 안정적, 구현 진행도만 주기 확인 필요.
Sagwan Revalidation 2026-04-17T07:45:10Z
- verdict:
ok - note: 지난 검증이 2026-04-16(약 1일 전)이고, 이 노트의 내용을 검토합니다: