Graphs are not enough
Knowledge graphs are introduced as a better way to represent relationships. True, and only the start. A graph describes suppliers, contracts, products, obligations, people, systems and controls. It answers questions that would be awkward in tables. It connects domains without flattening the business into one schema.
But an operational system needs more than representation. It needs a way to move change safely.
Most graph databases are live-state systems. There is a current graph, and writes mutate it. If an import is wrong, production is wrong. If a migration half-fails, the shared state is half-migrated. If two teams need to change different things at once, they coordinate outside the database, through tickets, meetings, frozen windows and rollback plans.
That is not logistics. It is shared mutable state with ceremony around it.
Legra starts from a different premise: operational knowledge needs the change path software teams expect for code. A change is isolated before it is shared, inspected before it is promoted, checked against declared rules, and keeps where it came from, who made it and which exact state existed at the time.
Logistics is movement
Storage answers where data lives. Logistics answers how data moves from one state to the next without losing control. For semantic data that means:
- branch the graph before changing it;
- stage imports, migrations and edits away from production;
- validate each proposed state against shapes and rules;
- diff branches and commits to see what changed;
- review the change before promotion;
- merge accepted work into a long-lived branch;
- replicate durable history to the nodes that need it;
- read past states when audit or reproduction demands it.
None of this is decoration. It is the difference between a graph used for analysis and a graph used as infrastructure.
Developers know the pattern: branch, commit, test, review, merge. Knowledge needs the same discipline, but plain Git is not enough: semantic data is a large, queryable, distributed graph, not a folder of files. Legra applies Git's principles to RDF without pretending otherwise.
Branch before you change
The first primitive is the branch. It gives work a place to happen. A bulk upload, a taxonomy update, an ontology refactor or a catalog refresh runs away from the long-lived branch other users depend on. The branch points at the existing state and records only what diverges from it.
That matters at scale. Copying a graph of billions of statements for every experiment is out of the question. Branching has to be routine. A branch that changes a small part of a large graph stores the changed content and shares the rest. That is what content addressing makes possible: old content is not overwritten, and new content gets a new address. On Legra, a branch costs nothing to create.
Stage the work
Not every branch has the same purpose. A long-lived branch is a published state that users, integrations and other nodes depend on. A transaction branch lives for one logical write. A staging branch is a longer-lived working area for building up a change before it lands.
Staging matters because real changes are incomplete for a while. A bulk upload processes hundreds of files. A pipeline creates entities first and relationships later. A steward repairs a classification tree in several passes. During that work, interim states are useful, committed and inspectable, and not ready to promote.
Staging gives the work a lifecycle. It collects commits, shows progress, carries warnings and stays isolated until it is ready.
Validate while building
A single check at the end of a pipeline is too late; authors need feedback while they build.
Legra separates two concerns that are usually tangled: which rule is enforced, and how strict the receiving branch is. A rule names the shapes that gate commits and the graphs they cover. The branch decides whether a violation rejects the commit or comes back as a warning. Long-lived branches are strict. Staging branches are lenient, so unfinished work can land while reporting what is not yet valid.
The rule does not change because the work is in progress. The same rule warns on staging and rejects on the protected branch. A person or a job keeps committing, reads the warnings and corrects the graph until the proposed state is clean. This is validation as a feedback loop rather than a late surprise.
Merge is promotion
Merge is promotion, not synchronization. When staged work is ready, the destination branch applies its own rules and rejects a merge that violates them. Validation becomes a gate at the point where shared state would change.
The useful property is convergence. If staging received the same feedback throughout, the author drives it to zero warnings before asking for promotion. The merge is then the final application of rules that were visible all along.
Review becomes concrete too. A reviewer does not inspect a claim that a pipeline ran. They inspect a diff between graph states: which statements were added, removed or changed, which named graphs were touched, which commit produced the state, which identity signed it. That is the subject of GitHub for Data. Here the point is narrower: for operational semantic systems, review is part of the path a change travels.
History is infrastructure
History is usually sold as an audit feature. Here it is more fundamental.
Every meaningful change produces a commit. Commits form a history of graph states that can be queried, compared, replicated and verified. A report, a model run, a compliance review or a decision can name the exact commit it used.
That differs from a transaction log on the side. A log says something happened. Versioned knowledge lets you inspect the state that existed when it happened. As Versioned Knowledge argues, reading the past and diffing it are what make data changes reproducible.
A team answers "what did we know when we decided?" without rebuilding state from backups and partial logs.
Where agents fit
Agents make the logistics layer more important, not less.
An agent should not get arbitrary write access to a production graph. It works in a scoped context, on a branch, through permitted operations, with validation feedback, provenance and a promotion gate. The branch boundary is where experiment is allowed. The merge boundary is where governance is enforced. On Legra, agents work under the same rules as people.
The path does not change because the author is a machine. It matters more, because a machine takes many small steps quickly, and each still needs context, isolation, validation and review.
Knowledge graphs describe the enterprise. Data logistics lets the enterprise change that graph without losing control of the change.
Try it in Legra
Practice the change lifecycle with branches and merges, then use the linked tutorial to compare a proposal with the shared branch.