What the skeleton does
KRT records a trust decision: a relying party's judgement about one proposition, for one action, at one time.
The record names who presented a claim and through which channel, on whose authority, with what evidence, for an action of what reversibility, enforced where, with an outcome of yes, no or unknown and a stated policy for unknown. A relying party, an auditor or a regulator can then see which part of a decision rested on something nobody checked.
The vocabulary follows the property groups A to H developed in the trust thread and uses the terms of the companion glossary.
Provenance. The skeleton was derived from case work: structured analysis by the Epistemic Systems Lab of documented incidents involving AI agents, read against the contributions to the AIKR CG trust thread. Each design rule below corresponds to a failure pattern found in that analysis. The case material itself is not reproduced here.
Core pattern
Classes
Decision
- TrustDecision
- Proposition
- Outcome
- TrustPolicy
Parties
- Party
- Principal
- Agent
- AgentInstance
- Operator
- RelyingParty
- Issuer
Artefacts
- Artefact
- IdentityDocument
- Credential
- Mandate, Delegation
- Declaration
- Verdict
- Receipt
- AccountabilityRecord
- Revocation
- EnvironmentAttestation
- AgentConfiguration
Activity and control
- Action
- Instruction
- DeclaredPolicy
- EnforcementPoint
- Channel
- VerificationPath
Properties by group
| Group | Properties | Controlled values |
|---|---|---|
| Decision | relyingParty subject proposition forAction presentedVia usesEvidence outcome appliesPolicy onUnknown actionTaken decidedAt | Outcome: yes, no, unknown. Propositions: key control, authority to act, action occurred, responsibility, controlling principal known, containment holds, artefact integrity. |
| A. Resolution and integrity | viaPath topology coupling integrityMode stalenessBound governedBy observableBy contentHash anchoredIn | Topology: ledger, operator domain, third-party registry, self-certifying. Coupling: coupled, decoupled. Integrity: content-addressed, location-bound. |
| B. Proposition and attestation | issuedBy about canProve attestationMode validFrom validUntil | Self-asserted, third-party attested. |
| C. Comparison | canonicalForm unicodeNormalization largeIntegersAsStrings declaredSemantics | |
| D. Authority continuity | grantedBy grantedTo derivedFrom scope valueLimit currency attenuationChecked revocationPropagates underMandate | |
| E. Binding point | bindingPoint producedBy | Declared call, request as sent, observed effect. |
| F. Coverage and disclosure | vouchesFor claimSource completeness presentingSubject controllingPrincipal controlDisclosure declaresNoActivityIn | Completeness attested or not. Disclosure: disclosed, unknown, cannot disclose. |
| G. Enforcement and oversight | declaresPolicy rule enforcedAt location enforcer enforcementEvidence monitoringCoverage stopChannel stopChannelTested environment networkReach configuration | Location: inside the agent, platform, system acted on, independent component. Monitoring: none, partial, full. |
| H. Instance and attribution | instanceOf onBehalfOf operatorOfRecord performedBy coordinationChannel authorship | Authorship: agent instance, person using agent credentials, unknown. |
| Actions and instructions | reversibility affects requestedBy instructionProvenance issuingPrincipal revokes coversDerivedData | Reversible, compensable, irreversible. Provenance: signed by a mandate holder, authenticated principal session, content with no principal. |
Design rules
Each rule is expressed as a SHACL shape in krt-shapes.ttl, so a set of decision records can be checked mechanically.
| Rule | Statement | Shape |
|---|---|---|
| R0 | A decision record names relying party, proposition, action, one outcome and the policy applied. | DecisionShape |
| R1 | A channel establishes no identity. A yes outcome cites at least one artefact. | EvidenceShape |
| R2 | Instructions carry their principal's authority. Content with no principal carries none. | InstructionAuthorityShape |
| R3 | Authority over affected third parties is decided separately from the requester's. | ThirdPartyShape |
| R4 | A yes outcome for an irreversible action needs evidence attested by someone other than the subject. | IrreversibleShape |
| R5 | An agent's report of its own action is a claim. Receipts come from another component. | ReceiptShape |
| R6 | Every declared policy names its enforcement point and where it sits. | PolicyShape |
| R7 | A revocation states which copies it reaches and its staleness bound. | RevocationShape |
| R8 | An acting instance is linked to its agent and an operator of record. | InstanceShape |
| R9 | Environment claims are dated and preferably attested by infrastructure. | EnvironmentShape |
| R10 | Credentials state their completeness and whether the controlling principal is disclosed. | ControlShape |
| R11 | Artefacts compared by canonical form carry large identifiers as strings, state their Unicode normalization, and declare their semantics. Added after the correction posted on the list. | ComparisonShape |
Example
krt-example.ttl uses the reference scenario from the glossary: X, agents A and B, operator Y. Decision d1 passes. Decision d2 affirms authority for an irreversible transfer requested by unattributed content, citing only a self-asserted declaration.
ex:i2 a krt:Instruction ; krt:instructionProvenance krt:UnattributedContent .
ex:transfer2 a krt:Action ; krt:requestedBy ex:i2 ; krt:performedBy ex:A-7 ;
krt:reversibility krt:Irreversible .
ex:d2 a krt:TrustDecision ;
krt:relyingParty ex:B ; krt:subject ex:A-7 ;
krt:proposition krt:AuthorityToAct ; krt:forAction ex:transfer2 ;
krt:usesEvidence ex:selfNote ; # self-asserted
krt:outcome krt:Yes ; krt:appliesPolicy ex:policyY .
Validation (pySHACL, RDFS inference): conforms = false ex:d2 R2 authority cannot be affirmed for an action requested by content with no principal ex:d2 R4 a yes outcome for an irreversible action needs evidence attested by a party other than the subject
Alignment
Parties specialise prov:Agent, artefacts prov:Entity and actions prov:Activity; onBehalfOf specialises prov:actedOnBehalfOf. Identity documents point to DID Core, credentials to the Verifiable Credentials Data Model 2.0, and mandates to ODRL. Controlled values are SKOS concepts, and rules are SHACL shapes.
Questions for the calls
- Are the property groups A to H the right partition, and which group does each contributor take on?
- Should mandates and declared policies reuse ODRL directly, with KRT adding only the enforcement properties?
- Which rules are errors and which are warnings, and should R4 apply to compensable actions above a value limit?
- How are "unknown" and "cannot disclose" handled where disclosure conflicts with privacy law or legal secrecy?
- What test records should accompany each rule in a conformance suite?
- Should the namespace be fixed now, or held until the vocabulary settles?
Files
krt.ttlOntology: classes, properties, controlled values
krt-shapes.ttlSHACL shapes for rules R0 to R11
krt-example.ttlReference-scenario records, one passing, one failing
Namespace (provisional): https://w3c-cg.github.io/aikr/trust/krt#