By correction
Your analyst opens a Task, fixes a low-confidence extraction, and marks the correction as a rule. The rule enters the Library bound to that customer or vendor, ready for the next document.
Knowledge Product · Knowledge
The rules your team already applies. Captured.
Every borrower files differently. Every vendor invoices differently. Your analysts know this. Knowledge is where what they know becomes the rules and exceptions inside the workflow — captured at the right grain, owned by your tenant, portable across foundation models.
Definition
Captured rules, not a black box.
A piece of Knowledge in Kodexa is a specific, reviewable rule about a specific customer or vendor. "Vendor X always puts the PO number in the comment field, not the header." "Borrower Y's quarterly statements show operating leases under 'Other Liabilities' until 2024." Each rule names what it does, when it fires, who last edited it, and what Activity uses it.
- A rule has an owner, a history, and a reason. It's not a model weight.
- A rule can be edited the same way your team would edit a spreadsheet formula they own.
- A rule is bound to the customer or vendor it applies to. Other tenants never see it.
The Library
Where your team's captured knowledge lives.
The Library is the surface inside Workflow where rules sit, grouped by customer or vendor, searchable, editable, and version-controlled. Your analysts go there to see what's captured, edit a rule that's drifted, or promote a one-off correction into a reusable rule.
Northwind Foods
14 active rules · bound to AP-Intake-v3 · last run 4m ago
Filter+ New rule
| Rule | Fires when | Last edit | Activity | |
|---|---|---|---|---|
| PO number in comments Header field empty → look at comments line | doc.header.po == null | M. Chen · 4d | Extract | |
| Tax line is VAT_RECOVERED Map to tax_recoverable on post | line.label == "Tax" | P. Adeyemi · 9d | Validate | |
| Freight on ≥ $5,000 invoices | total >= 5000 | M. Chen · 12d | Validate | |
| Group line items by ship-to Agent proposal · seen across 23 invoices | doc.ship_to.count > 1 | Agent · 1h | Extract | Review |
| Drop "Net 30" suffix on PO | po.endsWith("Net 30") | S. Park · 3w | Extract | |
| Multi-currency: USD only | currency != "USD" | M. Chen · 5w | Validate | |
| Map "DLV" to delivery line | line.code == "DLV" | P. Adeyemi · 6w | Extract |
Your analyst's correction lands here. The next time the workflow runs, it picks up the rule.
How it gets there
Three ways a rule enters the Library.
By agent proposal
An agent watches the corrections your team makes. When the same correction repeats across documents, the agent proposes a rule. Your team approves, edits, or rejects it.
By authoring
An analyst or a configurator opens the Library, names a rule, and writes its definition by hand. Useful for rules your team already knows about up front, before the first document arrives.
Why this is safe to put in production
The properties that make Knowledge yours.
Customer-owned
Knowledge is per-tenant. Your rules belong to your contract. They never cross to another customer, by design.
Reviewable
Every rule has an audit trail. Who created it, who edited it, what changed. The same audit trail as the rest of the workflow.
Model-portable
Foundation models change. The Library doesn't. The rules layer outlives the model behind it.
Editable like a spreadsheet
Rules are declarative definitions, not code. Your operators can edit one without filing a ticket.
The shape
Knowledge sits behind every Activity.
When an Activity Plan runs, the Activities pull in the rules from the Library that apply to the customer or vendor on the document. The same Plan running for two different vendors will follow two different sets of vendor-specific rules — same workflow, different Knowledge.
See the Library on your customers or vendors.
We'll show the Library populated with rules for a customer or vendor that looks like yours, and walk through how an analyst correction becomes a rule the next document picks up.