Datacore Improvement Proposals (DIPs)

DIPs are the primary mechanism for proposing new features, collecting community input, and documenting design decisions for Datacore.

What is a DIP?

A DIP is a design document providing information to the Datacore community about a proposed change. The DIP author is responsible for building consensus within the community and documenting dissenting opinions.

DIP Types

Type	Description
Core	Changes to the main datacore repo (personal spaces)
Org	Changes to datacore-org template (team spaces)
Module	New module proposals or module standards
Process	Changes to the DIP process itself

DIP Status

Read each DIP header and its explicit amendment, rollout and future-work notes together. An Implemented header does not ratify an explicitly proposed section or establish that every follow-up is deployed. Catalog rows mirror the referenced header; they do not override it.

Status	Description
Draft	Initial proposal, open for feedback
Review	Under formal review by maintainers
Accepted	Approved for implementation
Partial	Specification accepted, implementation in progress
Implemented	Merged and released
Rejected	Not accepted (with rationale)
Withdrawn	Withdrawn by author
Superseded	Replaced by a newer DIP or implementation
Deferred	Postponed for future consideration

DIP Workflow

1. Fork datacore-dips repo
2. Copy DIP-0000-template.md to DIP-XXXX-title.md
3. Fill in the template
4. Submit PR with status: Draft
5. Community discussion on PR
6. Maintainers move to Review
7. Accept/Reject decision
8. Implementation PR(s) to relevant repos
9. Status updated to Implemented

When to Create a DIP

Always create a DIP for:

• New patterns or conventions (like DIP-0002 Layered Context)
• Changes affecting multiple repos or components
• New agent types or command categories
• Privacy or security model changes
• Breaking changes to existing workflows

Small changes that DON'T need DIPs:

• Bug fixes
• Documentation typos
• Single-file improvements
• Performance optimizations

AI agents should automatically create DIPs when implementing significant system changes. This ensures all architectural decisions are documented and reviewable.

Before Submitting

1. Search existing DIPs - Your idea may already exist
2. Discuss first - Open a GitHub Discussion for initial feedback
3. Small changes - Bug fixes and minor improvements don't need DIPs

DIP Template

See DIP-0000-template.md for the template.

Current DIPs

Core Infrastructure

DIP	Title	Status
0001	Contribution Model	Implemented
0002	Layered Context Pattern	Implemented
0005	Installation & Upgrade	Implemented
0014	Tag Taxonomy	Implemented
0016	Agent Registry & Discoverability	Implemented

Knowledge & Content

DIP	Title	Status
0003	Scaffolding Pattern	Implemented
0015	Semantic Organization	Implemented
0017	Outbox & Archive Pattern	Implemented
0019	Learning Architecture	Implemented

GTD & Task Management

DIP	Title	Status
0009	GTD System Specification	Implemented
0010	External Sync Architecture	Implemented
0011	Nightshift Module	Implemented

Domain Modules

DIP	Title	Status
0012	CRM Module	Implemented
0013	Meetings Module	Implemented

Process & Templates

DIP	Title	Status
0000	DIP Template	Implemented

System Architecture

DIP	Title	Status
0021	Search & Research Architecture	Implemented
0022	Module Specification	Implemented

Infrastructure & Security

DIP	Title	Status
0018	Credential Management	Draft
0020	WhatsApp Module	Accepted

Historical / Superseded

DIP	Title	Status
0004	Knowledge Database	Superseded
0006	Open Questions Management	Superseded
0007	Inbox DONE Option	Superseded

---

Historical roadmap (not current number reservations)

This older planning list is retained for traceability. Its numbers and titles were superseded by the subsequently created DIP files and do not reserve numbers or define current implementation requirements:

DIP	Title	Purpose	Priority
0023	Sync Architecture	./sync script, multi-repo handling	Medium
0025	Evaluation & Benchmarking	datacore-bench: A/B testing, instrumentation, session replay	High
0026	Chat Interface Architecture	Telegram, Slack, Discord, Email integrations	Medium
0027	Journal Format	Personal and team journal structure	Low

Relationship to datacore-specification.md

With DIP-0017 through DIP-0021 complete, the monolithic datacore-specification.md can be reduced to a ~10KB overview document that:

1. Introduces Datacore philosophy and concepts
2. Links to specific DIPs for detailed specifications
3. Provides quick-start guidance

Current spec section → DIP mapping:

Spec Section	Covered By
Overview & Philosophy	Remains in spec (unique)
Core Concepts (Spaces)	Remains in spec (unique)
Core Concepts (Modules)	→ DIP-0022
Architecture	→ DIP-0003, DIP-0015
Knowledge Layer	→ DIP-0003, DIP-0015, DIP-0019
Task Management (GTD)	→ DIP-0009
Agents & Commands	→ DIP-0016
Configuration	→ DIP-0021
Git & Contribution	→ DIP-0001, DIP-0002
External Sync	→ DIP-0010
Operations	→ DIP-0017, DIP-0018
Integrations	→ DIP-0010
Chat Interfaces	→ (future DIP)

Contributing

1. DIPs must use the template
2. One DIP per PR
3. DIP numbers assigned by maintainers
4. Use clear, concise language
5. Include rationale and alternatives considered

Inspiration

This process is inspired by:

• Ethereum Improvement Proposals (EIPs)
• Python Enhancement Proposals (PEPs)
• Rust RFCs