RCD Notes & Hyperscope for GNU Emacs, The Dynamic Knowledge Repository


RCD Notes & Hyperscope for GNU Emacs

The Dynamic Knowledge Repository

RCD Notes & Hyperscope for GNU Emacs is a Dynamic Knowledge Repository designed as envisioned by Doug Engelbart. It is free software licensed under the GNU AGPL 3.0+.

It is programmed in Emacs Lisp and used through the GNU Emacs editor. It uses a PostgreSQL relational database as its storage backend.

Fundamental Principles

Any type of information may become an elementary object. Elementary objects have types, subtypes, and both internal and external properties. Types, subtypes, and properties enable infinite classification, categorization, and intersection. Documents are always related to people — to authors, destined people, related people, or as the subject matter itself.

Preamble: Types Shape Behavior

Before any object exists, its elementary object type and elementary object subtype determine how the system interacts with it. Types are not mere labels — they carry methods, Emacs Lisp behavior, major modes, colors, templates, and presentation rules.

A Video type behaves differently from a PDF type. A Task subtype has different lifecycle rules than a Receipt subtype. The type system is the executable grammar of the repository.

The Ten Principles

1. Any information is an elementary object

Every piece of information — a note, a person, a location, a transaction, a relationship, a property — is an elementary object. Each object has a unique ID and a UUID for stable identity across systems.

There is no hard separation between “content” and “metadata.” Metadata exists as internal information — intrinsic to the object itself, not as external relations.

Principle: Ontological flatness — no information is inherently more privileged than any other.

2. Every object has a type and may have a subtype

Types carry executable logic:

Subtypes carry additional semantics:

Principle: Typed universalism with executable behavior — types define not just classification but interaction.

3. Objects have internal metadata and external properties

Internal metadata lives on the object itself:

External properties are stored separately, linking an object to a Property (name) and Value, with an optional Extra value. Each external property has a Type (what kind of property it is) and a Description.

Principle: Intrinsic vs. relational — what something is (internal metadata) vs. what it has in relation to others (external properties).

4. Infinite classification, categorization, and intersection

An object can belong to multiple classification systems simultaneously:

No object is forced into a single parent. Intersection queries — “All Documents of subtype Letter in WRS Area X with Property Y” — are native and efficient.

Principle: Polyhierarchical, non‑exclusive membership — classification is a hypergraph, not a tree.

5. Every object is related to people

The system embeds people relationships throughout:

Relationship Meaning
Author Who created this object
Author Name Denormalized author name for fast lookup
Assigned to contact Person responsible for or destined to receive this object
Related person Single person associated with this object
Related people list Multiple people associated
Introduced by Who brought this object or relationship into existence
Report to Manager or supervisor context
Curator Person responsible for maintaining this object
Related business Organizational context

For people themselves, the system tracks:

For relationships between people:

Principle: People are the gravitational center — no object exists without human context, and relationships between people are first-class objects with their own lifecycle and metadata.

6. Objects are authored, versioned, and traced

Every object tracks:

Principle: Full provenance — who made it, when, what changed, and the object remains traceable across systems.

7. Objects have lifecycle and state

For financial context specifically: Reconciled flag indicates settlement against external records.

Principle: Lifecycle awareness — objects are born, change, expire, and can be retired, not just deleted.

8. Everything can relate to everything else

Multiple relation mechanisms:

Mechanism Meaning
Parent ID Hierarchical containment (object contains other objects)
Properties (with Type, Property, Value) Named, valued relationships to other objects or literals
Hyperdocument 1 / Hyperdocument 2 (with Relation type) Typed binary links between any two elementary objects
Person / People list (with Relation type) Typed relationships between people, with start/end dates, opt-outs, and sales stage

A transaction can link to: - Hyperdocument — the elementary object that contextualizes this transaction - Receipt — proof document - Payer, Receiver, Reporter — people involved - Relationship — the people-relationship under which this transaction occurred - From account, To account — financial accounts - Currency, Exchange rate - Last known location - Possession type, Stock, Unit, Unit Price

Principle: Graph-native — relations are not afterthoughts; they are first‑class objects with their own metadata. Everything can connect to everything.

9. Types have their own types (metatypes)

The type system is self-describing. Elementary object types themselves have:

Elementary object subtypes have:

Principle: Reflective typing — the type system is itself typed, extensible, and executable.

10. The repository is active, not passive

Triggers and constraints enforce domain logic automatically:

Types invoke action Lisp and PDF Lisp on demand. Subtypes carry action LL types that determine behavior at runtime.

Principle: Smart storage — the database and type system enforce business logic and integrity, not just the application.

Feature Areas

The principles above manifest in concrete feature domains that span personal, organizational, and enterprise needs — all unified under the same object model.

Customer Relationship Management (CRM)

Multiple Website Revision System (WRS)

Enterprise Resource Planning (ERP)

Hyperscope Dynamic Knowledge Repository (DKR)

Geographic Features

Encryption and Security Features

Semantic Triplets

Real Estate Management

Emacs Interface

Localization

One Sentence Summary for the Emacs User

RCD & Hyperscope is a typed, versioned, person‑centric, graph‑native object store where every document, person, transaction, property, and relation is a first‑class, searchable, lifecycle‑aware object — types carry executable Emacs Lisp behavior, major modes, colors, and templates — and Emacs is the interface to query, create, and traverse it across CRM, ERP, web publishing, geography, encryption, and beyond.

Does RCD Notes & Hyperscope, The Dynamic Knowledge Repository for GNU Emacs alignes with the principles of the the Dynamic Knowledge Repositories (DKR) as described by Doug Engelbart?:

Based on the Doug Engelbart definition you provided — without needing the failed URL fetch, since you quoted the essential text — yes, the RCD Notes & Hyperscope aligns directly with the Dynamic Knowledge Repository (DKR) concept. Here is a point‑by‑point alignment:

Alignment with Engelbart’s DKR Definition

Engelbart’s DKR Requirement How RCD Notes & Hyperscope Fulfills It
Not a static archive — a living, breathing, rapidly evolving repository Every object has Date Created, Date Modified, Revision, User tracking, Active flag, Expiration dates. The repository changes moment to moment.
Accumulates everything throughout a project — successive drafts, commentary, polished versions Version control trigger records every change. Parent ID allows draft → revision chains. Modification type tracks what changed.
Brainstorming and conceptual design notes Note type, Text content, Internal information field — brainstorming lives as elementary objects.
Design rationale Properties table (Property, Value, Extra value) captures rationale as structured external metadata. Description field holds free‑text reasoning.
Work lists Task subtype, TODO field in transactions, Checklist subtype, Priority and Global priority fields — actionable work items.
Contact info Full people table with names, prefixes, suffixes, departments, titles, addresses, communication opt‑outs, lead sources.
Email and meeting notes Message-ID type, Chat Log subtype, Meeting subtype, peoplerelations table links people to meetings. E‑mail Snippet and Signature subtypes.
Research intelligence collected and commented on Elementary objects of any type can have Description, Internal information, Properties, Related URIs, Tags. Comments are objects themselves.
Emerging issues Issue tracking via Action status, Follow‑up subtype, TODO fields, Sales Flow Stages for problems.
Timelines Start Date and Time, End Date and Time, Duration, Interval — temporal modeling built into every object.
Software project specifics — successive source code versions, bug reports, change requests, fixes, version release notes, documentation File type, PDF by Page Nr., Video (exact time), Emacs Lisp Hyperlink, Shell Command, Executable Snippet, Dev‑T subtype, Programming Language field, MIME types, Is file flag — code and bugs are objects with versioning.
CoDIAK (Concurrent Development, Integration, Application of Knowledge) Types carry executable Emacs Lisp — actions run on objects. Hyperdocument 1 / Hyperdocument 2 relations connect concurrent work. Action LL types trigger behaviors. The repository is active, not passive.
DKR as collective record captured on the fly Every object has User created, User modified, Date created — who did what, when, as it happens. No batch import required.
Group brain, memory, connecting dots Universal relations (Parent, Properties, Relatedhyperdocuments, Peoplerelations) connect any object to any other. Full‑text search (Tokens) finds dots. Hyperscope Ring remembers user paths.
Right hand knows what left hand is doing Assigned to contact, Related people list, People list assigned, Report to, Curator — people see objects assigned to them or their team. Sharing types control visibility.
Best practices: collaboration facilitators, knowledge specialists The system is programmable in Emacs Lisp — facilitators can write custom queries, views, templates. Templates table, Presentation templates, WRS Page Layouts encode best practices as reusable structures.
Moderating connectivity, capture, tagging, tracking Tags (#1, #2, #3), WRS Categories, WRS Areas, Keywords, Properties — multiple orthogonal classification systems. Search status controls indexing. Action status tracks workflow.
Portals into the emerging repository WRS (Multiple Website Revision System) serves repository content as HTML. Hyperscope Agenda provides personal portal. Org export, LaTeX export, HTML export — any view.
Optimally navigable, searchable, useful GIN indexes on Tokens (full text) and Text (trigram) for fast search. Hyperscope Ring for navigation history. Parent ID for hierarchy. Relatedhyperdocuments for graph traversal.
Litmus test: find design flaw from several versions back, with dialog, commentary, rationale, alternatives Version control trigger keeps history. Parent ID chains versions. Properties table stores rationale. Relatedhyperdocuments links decisions to discussions. Internal information holds private commentary. Description holds public rationale. — All pieces instantly accessible because they are objects with relations, not buried in email.
No digging through everyone’s emails Email is ingested as objects (Message-ID type, Mbox type). Email becomes part of the graph, not a separate silo.
Comprehensive knowledge base on a topic (Human Genome Project, Library of Congress, Wikipedia, Internet Archive) Any domain can be modeled: Real estate management, Geographic features, Financial subjects, Health remedies, Legal documents (Law, Patent, Contract), Educational (Lesson, Training), Creative (Poem, Song, Story, Movie) — all as types/subtypes.
Quality, breadth, depth → Collective IQ The system’s typed, relational, versioned, searchable, executable nature directly raises Collective IQ per Engelbart’s metric.

Direct Quote Alignment

“A DKR is a living, breathing, rapidly evolving repository of all the stuff accumulating moment to moment throughout the life of a project or pursuit.”

RCD: Every object has creation/modification timestamps, revision numbers, user tracking, and active/expiration states. The repository changes in real time, not in batches.

“Successive drafts and commentary leading up to more polished versions.”

RCD: Parent ID chains drafts. Version control trigger records every change. Modification type distinguishes draft from published.

“Brainstorming and conceptual design notes, design rationale, work lists, contact info, all the email and meeting notes.”

RCD: Note type, Properties table for rationale, Task subtype, People table, Message-ID and Mbox types, Meeting subtype, Chat Log subtype.

“Research intelligence collected and commented on.”

RCD: Any object can have Description, Internal information, Properties, Tags, Related URIs. Comments are separate objects linked via Relatedhyperdocuments.

“In a software project: successive versions of source code, bug reports, change requests, fixes, version release notes, documentation.”

RCD: File type, Dev‑T subtype, Programming Language field, Is file flag, PDF by Page Nr., Video (exact time), Executable Snippet — all versioned and linkable to people, tasks, and meetings.

“CoDIAK — concurrent development, integration, and application of knowledge.”

RCD: Types carry executable Emacs Lisp (application). Hyperdocument relations connect concurrent work (integration). Action LL types trigger behaviors (development). The repository is active, not a static archive.

“The DKR is the emerging collective record captured on the fly — the group brain, memory, where the dots are connected.”

RCD: Universal relations connect any object to any other. Full‑text search finds dots. Hyperscope Ring remembers paths. Peoplerelations connects people to people and people to work.

“A litmus test: instant access to design documents several versions back, with dialog, commentary, design rationale, alternatives discussed.”

RCD: Version control + Parent ID chains. Properties table stores rationale. Relatedhyperdocuments links decisions to discussions. All objects, not email silos. Instant, not after digging.

“No digging through everyone’s emails to piece together what was transpiring.”

RCD: Email is ingested as objects (Message-ID, Mbox). Email becomes part of the typed, related, searchable graph.

Conclusion

Yes, RCD Notes & Hyperscope aligns fully with Engelbart’s DKR vision. It is not merely a document archive — it is a typed, relational, versioned, searchable, executable, person‑centric, graph‑native repository that captures work in real time, connects everything to everything, and makes the collective record instantly navigable. It implements CoDIAK through executable types and universal relations. It passes the litmus test: old designs, rationale, alternatives, and discussions are all objects — accessible directly, not buried in email.

The one addition Engelbart emphasizes that the current documentation could make more explicit is the social and role dimension. The system already supports this through fields such as Assigned to, Curator, Introduced by, Report to, People list, and Peoplerelations with opt‑outs and sales stages. However, making it a stated principle — that the DKR includes roles and practices, not just technology — would fully close the gap between the implementation and Engelbart’s vision of collective work supported by collaboration facilitators, knowledge specialists, and evolving best practices.