Knowledge Base Architecture
Why CNL-PL uses in-memory bitsets instead of SQL, and how the RelationMatrix powers instant reasoning.
The In-Memory KB
The KB (Knowledge Base) is the runtime engine of CNL-PL. Unlike traditional systems that might store data in a SQL database or a Triple Store, the CNL KB is designed entirely around Bitset operations. This design choice is driven by the specific needs of logical reasoning: the need to perform massive set intersections and unions (AND/OR operations) instantly.
In a standard database, finding "all users who are admins AND active" involves joining tables and filtering rows. In the CNL KB, this is a single CPU-native bitwise AND operation between two bitsets. This allows the reasoning engine to validate complex rules over millions of entities in milliseconds, enabling real-time feedback loops that would be impossible with disk-based storage.
RelationMatrix and Storage
Binary relations (like "user accesses file") are stored in a specialized structure called a RelationMatrix. This is not a simple adjacency list. It is a collection of bitsets, where every row corresponds to a subject and the bits set in that row represent the objects it relates to.
This layout enables extremely fast "forward" traversal. To find everything a user accesses, you simply retrieve one bitset. However, the KB also maintains Inverse Indices. A parallel RelationMatrix stores the transpose of the data, allowing "backward" traversal (finding all users who access a specific file) with the same O(1) efficiency. This dual-indexing strategy is expensive in terms of memory but optimal for the graph-traversal nature of logical proofs.
Numeric and Entity Attributes
Not all data fits into a bitset. Attributes like "salary" or "temperature" require a NumericIndex. This is a column-oriented storage array, similar to what you might find in high-performance analytics databases like ClickHouse, but simplified. It maps an entity's internal ID directly to a float or integer value.
Similarly, the EntityAttrIndex handles functional relationships where an entity points to exactly one other entity (like "parent" or "owner"). While these could be stored in a RelationMatrix, knowing that a relationship is "functional" (1-to-1 or N-to-1) allows for further optimizations in storage density and query planning.