Kival does not require a folder tree or a predefined ontology. Start with knowledge worth preserving, give each piece a clear object identity, and add structure where it becomes useful.
Choose useful object boundaries
Create an object when something should have its own durable identity: its own history, access, discussion, attachments, or relationships.
A decision, runbook, project brief, research synthesis, source, or shared instruction can all be objects. Keep related material on the same object while it is still the same underlying thing; create a new object when it needs to stand independently.
Write the current understanding
An object's title, body, and metadata are versioned together. Editing them creates a new immutable version while the object's identity remains stable.
Write for the reader who arrives later. Capture the current conclusion or procedure in the object itself, not only in commentary or an external chat thread. Earlier states remain available in version history.
Add lightweight structure with metadata
Metadata is a flat JSON object of scalar values or one-dimensional scalar arrays. It is useful for stable attributes such as an external identifier, status, category, owner name, or source type.
Avoid using metadata as a second document body. Put explanation and reasoning in the body; use metadata for compact attributes that are useful to people or integrations.
Connect related knowledge
Use explicit relationships when you deliberately want two objects connected. Use supported references in the body when the connection belongs naturally in the authored text.
These are complementary. Relationships are graph state; references preserve the fact that one object version actually mentioned another.
Attach source material when useful
Objects can carry attachments such as source files or supporting artifacts. Attachments remain associated with the object and are protected by its access boundary.
Treat an attachment as supporting material, not a replacement for durable Kival knowledge. If a file leads to a conclusion, decision, procedure, or synthesis that should be searchable and maintainable, write that result into the object's body and keep the file as supporting context.
Use personal navigation for personal attention
Favorites and pins help you return to objects you use often. They belong to the individual user and do not change shared object structure. Recent objects provide another way back into actively changing knowledge.
Use metadata, relationships, references, and authored content for structure that should be shared. Use favorites and pins for your own attention.
Archive instead of deleting history
Archive an object when it should leave ordinary active use but its identity and history still matter. Restoring it brings the same object back with its versions intact.
Do not archive simply because the knowledge changed. If it is still the same subject, update the object. Archive is for moving the object itself out of active use.
Let conventions emerge
A useful workspace does not need a comprehensive schema on day one. Start with clear objects and useful content. Add metadata and connections when repeated needs appear. Over time, the structure can reflect how the team actually works rather than how someone predicted it would work before the knowledge existed.