schemaVersion: requirement-record.v1
revision: R2
status: needs-design
priority: P0
productOwner: "@PeterGuy326"
technicalOwner: "unassigned"
userOutcome: "Organization maintainers can prioritize cross-repository work against one explicit vision sentence, module boundaries, invariants, and evidence-based delivery order."
requirements:
- REQ-001
- REQ-002
- REQ-003
- REQ-004
acceptanceCriteria:
- AC-001
- AC-002
- AC-003
- AC-004
- AC-005
parent: null
dependencies: []
supersedes:
- "R1 unnumbered scope/acceptance draft"
lastDecisionAt: "2026-08-23T06:18:01Z"
Context
Why this RFC exists
The organization already has three complementary products, but the shared product promise and the boundaries between them are not yet explicit enough to guide prioritization. That creates two risks:
- each repository can optimize locally without producing a coherent digital-employee system; and
- marketplace or hosted-service work can start before portability, provenance, permissions, and safe execution are credible.
This RFC proposes a shared north star, crisp module boundaries, and an evidence-based delivery order.
Proposed organization vision
ByteFolk builds open, self-hostable runtime and data planes that let reliable AI agents become durable digital employees—while memory, working documents, permissions, and execution remain portable, inspectable, and controlled by users.
The organization sits between models and production systems. It does not own the model and it does not require a hosted control plane.
Product map and boundaries
mem — memory and context plane
Owns durable evidence, memories, task state, recall, feedback, forgetting, and portable handoff.
- Must preserve source locators and correction history.
- Must support export/import independently of any employee runtime.
- Must not become a chat product, document editor, or agent orchestrator.
doc — collaborative artifact plane
Owns editable human/agent documents, collaboration, access, review, versions, recovery, publishing, and portable document bundles.
- Must keep AI-proposed content inside the same review and version boundaries as human changes.
- Must expose stable APIs instead of hidden database coupling.
- Must not become an agent runtime or duplicate durable memory.
digital-employee — role runtime and policy plane
Owns versioned employee profiles, channel/model/source neutrality, connector loading, tool policy, approval, escalation, and runtime observability.
answer-agent is the first shipped profile, not the runtime architecture.- DWS is optional; the console path must work with no DingTalk, DWS, or model credentials.
- The runtime must consume
mem and doc through explicit contracts rather than importing their storage.
Future registry/marketplace — distribution and trust plane
A registry or marketplace may distribute versioned employee packages and verified components. It should not be built until package compatibility, provenance, permissions, signatures, safe execution, and usage evidence are defined and demonstrated.
Organization-wide invariants
Every module and integration should preserve these properties:
- Self-hostable: the application layer works without a mandatory hosted control plane.
- User-owned and portable: data, employee packages, and artifacts have documented export paths.
- Provider-neutral: runtime contracts do not encode one channel, model, source, or vendor.
- Least privilege: reads use explicit allowlists. Writes require separate authority plus preview, idempotency, audit, and human approval where applicable.
- Human review boundaries: model output never silently becomes a durable fact or committed document revision.
- Provenance: consequential answers and actions retain source locators, revisions, and execution evidence.
- Evidence over claims: maturity labels, tests, and reproducible records determine what is called production-ready.
- No secrets by default: demos and tests run without credentials and never commit personal or internal data.
Cross-repository north-star scenario
The first shared acceptance scenario should prove one durable digital employee rather than a broad marketplace:
- Install the same versioned employee profile in Console and one optional external channel.
- Resume a durable task from
mem across sessions/channels, with exact citations and scoped identity.
- Read an explicitly approved
doc revision as a knowledge source.
- Turn a requested document change into a reviewable proposal, not an immediate mutation.
- Commit an approved change idempotently and record an audit trail.
- Export the employee package, memory workspace, and document bundle independently.
- Run the credential-free console demo throughout the implementation.
The scenario is complete only when its behavior is covered by observable tests and a reproducible demo record.
Delivery order
Phase A — contracts and trustworthy cores
- Publish a versioned employee-profile manifest and compatibility rules.
- Finish
mem's correction/index-generation contracts.
- Make
doc collaboration revocation, recovery, and production migrations credible.
Phase B — read-only cross-plane integration
- Add
mem as a scoped durable-context backend.
- Add version-addressed
doc content as an explicitly allowlisted source.
- Prove the cross-channel resume and cited-answer flow without enabling writes.
Phase C — reviewable actions
- Define preview, approval, idempotency, and audit contracts for write-capable tools.
- Add active-room-aware document mutation and an agent proposal/review/commit flow.
- Feed observed use/feedback into memory ranking without losing provenance.
Phase D — distribution and ecosystem
- Define signed bundles, dependency/capability declarations, compatibility checks, and provenance.
- Validate several independently maintained profiles/connectors.
- Only then evaluate registry, marketplace, metering, or hosted-service work.
Evidence used
This proposal is based on the current repository code and docs as of 2026-08-01:
mem already has strong handoff/forget foundations but calls automatic consolidation, immutable correction/supersede, and evaluated versioned ranking unfinished.doc has working Yjs collaboration and recovery foundations, while active-room mutation, immediate revocation, audit, portable bundles, production migrations, and object-storage neutrality remain gaps.digital-employee ships a useful answer-agent, but the schema and runtime assembly still hard-code that profile and known connector types; mem/doc are not runtime integrations yet.
This RFC intentionally turns those facts into a sequencing decision rather than promising unimplemented capability.
Requirements
REQ-001 — Adopt the vision sentence and module boundaries
Maintainers adopt the organization vision sentence and the module boundaries for mem, doc, digital-employee, and the future registry/marketplace as the shared north star guiding prioritization.
REQ-002 — Hold the organization-wide invariants
Every module and integration preserves the eight invariants: self-hostable, user-owned and portable, provider-neutral, least privilege, human review boundaries, provenance, evidence over claims, and no secrets by default.
REQ-003 — Follow the evidence-based delivery order
Sequence work through Phase A (contracts and trustworthy cores), Phase B (read-only cross-plane integration), Phase C (reviewable actions), and Phase D (distribution and ecosystem); registry, marketplace, metering, or hosted-service work is evaluated only after Phase D prerequisites are defined and demonstrated.
REQ-004 — Cascade the RFC into repository governance
Each public product repository gets outcome-based milestones and a roadmap epic linked to this RFC; cross-repository work gets one explicit north-star acceptance issue; existing work is assigned to a milestone or intentionally left in backlog; READMEs/GOAL documents are updated in separate reviewable pull requests after this RFC is accepted.
Acceptance Criteria
AC-001 — Vision and boundaries agreed
Maintainers agree on the vision sentence and module boundaries.
AC-002 — Milestones and roadmap epics linked
Each public product repository has outcome-based milestones and a roadmap epic linked to this RFC.
AC-003 — One north-star acceptance issue
Cross-repository work has one explicit north-star acceptance issue.
AC-004 — Existing work dispositioned
Existing work is assigned to a milestone or intentionally left in backlog.
AC-005 — README/GOAL updates in separate reviewable PRs
READMEs/GOAL documents are updated in separate reviewable pull requests after this RFC is accepted.
Non-goals
Near-term non-goals stated in R1:
- A hosted multi-tenant control plane.
- Billing, rentals, or marketplace ranking.
- Autonomous write access without an explicit approval contract.
- Tight database coupling across repositories.
- Hardware orchestration before software capability and safety contracts are stable.
Decisions
Status and evidence
- Status: needs-design; Priority: P0
- Baseline (as of 2026-08-01 per R1 evidence):
mem has strong handoff/forget foundations with consolidation, correction/supersede, and ranking unfinished; doc has working Yjs collaboration and recovery foundations with mutation, revocation, audit, bundles, migrations, and storage-neutrality gaps; digital-employee ships answer-agent with hard-coded profile/connector assumptions and no mem/doc runtime integration.
- Latest accepted implementation ledger: none
Change history
| Revision |
Effective time |
Decision |
Superseding comment |
| R1 |
2026-08-01T06:36:55Z |
Initial unnumbered scope and acceptance |
Initial body |
| R2 |
2026-08-23T06:18:01Z |
Formalize requirement-record.v1 with numbered REQ/AC, owners, and ledger |
This edit |
Context
Why this RFC exists
The organization already has three complementary products, but the shared product promise and the boundaries between them are not yet explicit enough to guide prioritization. That creates two risks:
This RFC proposes a shared north star, crisp module boundaries, and an evidence-based delivery order.
Proposed organization vision
The organization sits between models and production systems. It does not own the model and it does not require a hosted control plane.
Product map and boundaries
mem— memory and context planeOwns durable evidence, memories, task state, recall, feedback, forgetting, and portable handoff.
doc— collaborative artifact planeOwns editable human/agent documents, collaboration, access, review, versions, recovery, publishing, and portable document bundles.
digital-employee— role runtime and policy planeOwns versioned employee profiles, channel/model/source neutrality, connector loading, tool policy, approval, escalation, and runtime observability.
answer-agentis the first shipped profile, not the runtime architecture.memanddocthrough explicit contracts rather than importing their storage.Future registry/marketplace — distribution and trust plane
A registry or marketplace may distribute versioned employee packages and verified components. It should not be built until package compatibility, provenance, permissions, signatures, safe execution, and usage evidence are defined and demonstrated.
Organization-wide invariants
Every module and integration should preserve these properties:
Cross-repository north-star scenario
The first shared acceptance scenario should prove one durable digital employee rather than a broad marketplace:
memacross sessions/channels, with exact citations and scoped identity.docrevision as a knowledge source.The scenario is complete only when its behavior is covered by observable tests and a reproducible demo record.
Delivery order
Phase A — contracts and trustworthy cores
mem's correction/index-generation contracts.doccollaboration revocation, recovery, and production migrations credible.Phase B — read-only cross-plane integration
memas a scoped durable-context backend.doccontent as an explicitly allowlisted source.Phase C — reviewable actions
Phase D — distribution and ecosystem
Evidence used
This proposal is based on the current repository code and docs as of 2026-08-01:
memalready has strong handoff/forget foundations but calls automatic consolidation, immutable correction/supersede, and evaluated versioned ranking unfinished.dochas working Yjs collaboration and recovery foundations, while active-room mutation, immediate revocation, audit, portable bundles, production migrations, and object-storage neutrality remain gaps.digital-employeeships a usefulanswer-agent, but the schema and runtime assembly still hard-code that profile and known connector types;mem/docare not runtime integrations yet.This RFC intentionally turns those facts into a sequencing decision rather than promising unimplemented capability.
Requirements
REQ-001 — Adopt the vision sentence and module boundaries
Maintainers adopt the organization vision sentence and the module boundaries for
mem,doc,digital-employee, and the future registry/marketplace as the shared north star guiding prioritization.REQ-002 — Hold the organization-wide invariants
Every module and integration preserves the eight invariants: self-hostable, user-owned and portable, provider-neutral, least privilege, human review boundaries, provenance, evidence over claims, and no secrets by default.
REQ-003 — Follow the evidence-based delivery order
Sequence work through Phase A (contracts and trustworthy cores), Phase B (read-only cross-plane integration), Phase C (reviewable actions), and Phase D (distribution and ecosystem); registry, marketplace, metering, or hosted-service work is evaluated only after Phase D prerequisites are defined and demonstrated.
REQ-004 — Cascade the RFC into repository governance
Each public product repository gets outcome-based milestones and a roadmap epic linked to this RFC; cross-repository work gets one explicit north-star acceptance issue; existing work is assigned to a milestone or intentionally left in backlog; READMEs/GOAL documents are updated in separate reviewable pull requests after this RFC is accepted.
Acceptance Criteria
AC-001 — Vision and boundaries agreed
Maintainers agree on the vision sentence and module boundaries.
AC-002 — Milestones and roadmap epics linked
Each public product repository has outcome-based milestones and a roadmap epic linked to this RFC.
AC-003 — One north-star acceptance issue
Cross-repository work has one explicit north-star acceptance issue.
AC-004 — Existing work dispositioned
Existing work is assigned to a milestone or intentionally left in backlog.
AC-005 — README/GOAL updates in separate reviewable PRs
READMEs/GOAL documents are updated in separate reviewable pull requests after this RFC is accepted.
Non-goals
Near-term non-goals stated in R1:
Decisions
Status and evidence
memhas strong handoff/forget foundations with consolidation, correction/supersede, and ranking unfinished;dochas working Yjs collaboration and recovery foundations with mutation, revocation, audit, bundles, migrations, and storage-neutrality gaps;digital-employeeshipsanswer-agentwith hard-coded profile/connector assumptions and nomem/docruntime integration.Change history