4.3 KiB
profile, outbound, required_by_stack
| profile | outbound | required_by_stack | ||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| entities |
|
false |
kb/entities/ - Collection Contract
Concrete things that exist: a project, a deployed system, a CLI tool, a technology, a person or an organization. If it can be pointed at, it is an entity.
Quality goal: pointability + currency - a reader should come away knowing what the thing is, where it actually is, and whether that is still true. An entity page that describes a system correctly but names no host, path, version or status has not earned its keep.
Inherits kb/CONTRACT.md for the rules the stack enforces - linking mechanics, provenance, citation, the confidence machinery - and kb/CONVENTIONS.md for what this instance decided: language, naming forms, tone, relationship labels, the confidence rubric. Neither is restated here.
Types offered
entity (tools/wikitool types describe entity). The entity_type: field selects the area:
| Area | Holds |
|---|---|
projects/ |
Codebases and initiatives, named after their repository or common name |
systems/ |
Deployed and running systems, given a descriptive name |
tools/ |
CLI and desktop tools, named as the tool names itself |
technologies/ |
Protocols, languages, formats, in their standard spelling and capitalization |
people/ |
People and organizations, by full name or common handle |
These are areas, not collections: they inherit this contract and carry no COLLECTION.md.
Per-area emphasis
- Projects - purpose, status, language/stack, owner, repository, dependencies on other projects and systems, architectural decisions.
- Systems - purpose, components, dependencies, configuration locations, deployment, operational status, monitoring.
- Technologies - purpose, use cases, trade-offs, version compatibility, which projects and systems use it.
- Tools - purpose, installation, usage, notable options, which projects use it.
- People - role, affiliation, and the projects or decisions they are connected to. Nothing personal beyond what the source states.
Authorised labels
The outbound: block above is what wikitool lint and xref add check: which labels a page in
this collection may use, per destination. The catalogue they are drawn from - and what each one
asserts - is instructions/link-taxonomy.md, which binds
nothing on its own.
Operational labels dominate here because an entity's relationships are mostly to other concrete things. implements points out to a concept; the concept does not point back unless that direction is a statement of its own.
Three of these carry a caveat this area produces more often than the others. authored belongs
on a person page pointing at what they made, and it is the label a dead or departed creator
takes - owns claims someone answers for the thing now. alternative-to is self-dual and is
written once per pair, never from both ends: a set of interchangeable tools is where a
mirrored clique grows fastest. derived-from and adapted-from are here for the fork and the
re-implementation - one tool worked up out of another - which is a lineage claim the operational
labels cannot make.
Adding a label here is a deliberate contract change, not a way around a refusal.
Outbound linking
An entity links to the technologies it uses, the systems it runs on, the projects that depend on it, and the concepts it implements.
An entity that mentions a concept without linking it is incomplete; the concept page is where the why lives, and the entity page should not restate it.
What does not belong here
- A pattern, protocol, architecture or decision - those are concepts, even when only one entity uses them.
- A page about a source document - that is a
sourcepage inkb/sources/. - Singular naming is required:
HA Integration.md, notHA Integrations.md.