Knowledge Contract
Not a prompt but a contract: a bounded set of knowledge, rules and obligations for a specific task.
The contract, on one real task
A real task: "research the market for a new product". Here is its contract in plain words:
- Know
- the research methodology, the product glossary, and the boundaries of the market the client is asking about.
- Can
- search open, verifiable sources and spend time and budget within the agreed limit.
- Must not
- invent sources, present hypotheses as facts, or exceed the agreed budget.
- Success
- a report with methodology, sources and limitations, accepted by the client against criteria named in advance.
The four human questions
What the executor must know
Roles, skills, blueprints and task context, selected from the Professional Knowledge Graph for the specific work.
What it may do
Explicit permissions: tools, actions, access boundaries.
What it must not do
Constraints and policies: forbidden actions, data boundaries, safety rules.
How success is defined
Acceptance criteria, checks, and the Evidence the result must present.
How the contract is enforced during execution
The Resolver assembles the Knowledge Contract from versioned artifacts of the knowledge graph — checking versions, dependencies and policies — and records a Resolution Receipt: what was selected, what was excluded and why. Execution leaves a trace: the roles, skills, blueprints and constraints of every task are recorded in the Workflow Ledger and visible in the public Workflows.
A live example
Every published Workflow carries a "Knowledge Contract of the case" block — that is the contract of a concrete task.
Scientific foundation
The approach builds on the Arcanada publication "Meaning Management / Knowledge Contract Architecture" and evolves together with the Capability Atlas. The second version of the work adds the implementation and the measurements.