Core concepts
Rulith keeps a record of what is known, what supports it, what may run and what has actually completed.
Agent, Board and Case
An Agent is the identity that requests work. Its Board is a shared evidence graph, not a separate isolated database for every task.
A Case identifies one piece of governed work. It has an ID, a Case Type and, where required, a business key. The business key identifies the object being handled; a Case ID identifies that particular piece of work.
Two Cases can use shared facts. A capability's predicates and rules must carry the business keys needed to distinguish their objects. Choosing a Case in the UI does not make an ambiguous rule safe or automatically add a Case filter to it.
A conversation is local interaction history. It may discuss several Cases; clearing or archiving a conversation does not close those Cases.
Capability and Constitution
A Capability contains Vocabulary, Rules, Actions and Sources. It can declare Case Types and their acceptance contracts. An installed Release supplies executable definitions.
A Constitution is separate governance. It can add review or authorization requirements. Installing a capability does not grant its Sources unlimited access to local resources.
Evidence and grounding
| Term | Meaning |
|---|---|
| Clue | A model-provided proposal or unverified input; useful for finding evidence |
| Asserted | A claim recorded at its permitted assertion level |
| Attested | A claim backed by the designated, authorized Source |
| Derived conclusion | A result supported by rule premises; its strength cannot exceed the required support |
The installed rule or Action determines the required evidence. The model cannot raise a claim's tier by repeating it or labelling it trustworthy. Tool success does not certify unrelated business claims.
Actions, Tools, Sources and Connections
An Action defines permitted work and its conditions. A Tool implements an operation. A Source names the evidence origin and its authorized claims. A Connection binds an Agent to a Worker or observation producer.
The model requests an Action using the inputs shown in the current view. The service checks the request. A Worker executes admitted work with its local tool configuration and returns evidence of the result.
A listed Action is not a blanket permission: its current prerequisites can still refuse a call.
Completion and interruption
A request to close a Case does not prove completion. A certified completed Case must satisfy the installed acceptance conditions and any required verification. Other dispositions record that work ended without certified success.
An unknown execution result is different from failure. Do not replay an external operation to discover what happened. Preserve the original call identity and use the available inspection or recovery flow.
Closing one Case does not close another or delete every shared fact. Terminal receipts retain the evidence needed for the recorded outcome. Local artifacts still depend on their custodian retaining the original bytes.