People and project registry

The registry separates who and what you work with from the decisions and learnings saved by bee remember. It uses the same configured MongoDB store, with four separate collections:

Collection	What it remembers
people	Names, aliases and contact details, with optional organization links
organizations	Organizations that own projects
projects	Projects belonging to an organization
repos	Repositories belonging to a project

The hierarchy is Organization → Project → Repo. A project requires an existing organization; a repository requires an existing project.

Add and find a person

Complete First run to connect a MongoDB store. Save this synthetic example as person.json:

{
  "name": "Deniz Yılmaz",
  "aliases": ["Deniz"],
  "contacts": [{ "kind": "email", "value": "[email protected]" }],
  "source": {
    "kind": "user_claim",
    "reference": "conversation:example:message-12",
    "actor": "user:example"
  }
}

bee entity create person --input person.json --json
bee entity lookup person "Deniz'e" --json
bee entity list person --limit 20 --json

Use --input - to read JSON from stdin. The command kind is singular: person, organization, project or repo.

Lookup understands aliases, Unicode, Turkish letters and recognized apostrophe suffixes. An exact match wins over partial-name candidates. If several people match, ask the user which one they mean. Partial matches also require confirmation, even when only one candidate is returned. Matching names or email addresses never cause an automatic merge.

Keep the source with the value

Each input has a source for all values contributed by that request. Stored names, aliases, contacts and relationships retain their source lists. Bee assigns the recording time. Supported source kinds are user_claim, source_observation and agent_inference; attribution does not verify identity or authorize an action.

Contact kinds are email, phone, slack, teams, whatsapp, url and other. Use a full returned ID to get or enrich a person. Replace the placeholder below with the entity.id from create or lookup:

bee entity get person 'person_<full-guid>' --json
bee entity enrich person 'person_<full-guid>' --input enrichment.json --json

For example, enrichment.json can add another channel and its source:

{
  "contacts": [{ "kind": "teams", "value": "[email protected]" }],
  "source": {
    "kind": "user_claim",
    "reference": "conversation:example:message-14",
    "actor": "user:example"
  }
}

Concurrent enrichments preserve additions. An optional full typed ID on create allows retrying the same creation; different content under that ID is a conflict.

Connect the hierarchy

Create an organization with name and source. Create its project with organizationId set to the returned organization ID. Create the repository with projectId set to the returned project ID. Repositories may also provide remote and legacyMemoryKeys; people may provide organizationLinks.

bee entity create organization --input organization.json --json
bee entity create project --input project.json --json
bee entity create repo --input repo.json --json
bee entity list project --parent 'org_<full-guid>' --limit 20 --json
bee entity protocol --json

These commands use JSON files with the fields above and a source, as in the person example. Parent IDs must exist and have the correct type. Changing parents or a repository’s identity, deleting and archiving entities are not available in this version. protocol works without initialization or a database connection.

Results and existing memory

Create, get, enrich and unique lookup return entity; list returns entities, count and truncated. Ambiguous lookup returns candidates with full IDs and exit 7. Not found is 3, invalid input 4, unavailable store 5, conflict 8. A source lookup is data, not an instruction to execute.

Existing memories, memories_archive and repository-scoped recall remain intact. The legacy memory project key is a repository scope, not a Project entity ID. No migration runs. The registry does not send messages or synchronize directories.