Add CCL#58
Conversation
…y approval CCL (Corroboration & Consensus Language) is a deterministic DSL for expressing how a paranet decides whether shared DKG facts are sufficient to support, reject, or promote a claim. We need it so agents and nodes can evaluate the same approved policy over the same snapshot, produce the same result, and turn paranet governance into something replayable, auditable, and domain-specific instead of relying on ad hoc reasoning.
856f515 to
46a5a33
Compare
| if (!record) return null; | ||
| const bindings = await this.listCclPolicyBindings({ paranetId: opts.paranetId, name: record.name }); | ||
| const latestByScope = this.selectLatestNonRevokedBindings(bindings); | ||
| const active = this.resolveCclPolicyBinding(latestByScope, opts.paranetId, record.name, opts.contextType); |
There was a problem hiding this comment.
🔴 Bug: getActiveCclPolicyBinding() reuses resolveCclPolicyBinding(), which falls back to the default binding when there is no exact contextType match. In revokeCclPolicy() that lets --context-type ... revoke the default policy for every context instead of failing. For revocation, require an exact-scope binding whenever a context type was supplied.
| } | ||
|
|
||
| if (invalidBindings.size === 0) return quads; | ||
| return quads.filter(q => !invalidBindings.has(q.subject)); |
There was a problem hiding this comment.
🔴 Bug: this only strips quads whose subject is the invalid binding. approveCclPolicy() also gossips policyStatus / approvedBy / approvedAt on the policy URI, so a forged approval still mutates stored policy metadata even though the binding is rejected. Reject the whole payload, or also remove the companion policy-subject quads for invalid bindings.
| if (Array.from(latestByScope.values()).some(binding => binding.policyUri === policyUri)) { | ||
| return 'approved'; | ||
| } | ||
| if (bindings.some(binding => binding.policyUri === policyUri)) { |
There was a problem hiding this comment.
🟡 Issue: any policy that ever had a binding but is no longer the latest active one is reported as revoked here, even when it was only superseded by a newer approval. That makes the status field misleading and breaks status=revoked filtering. Distinguish explicit revocation from superseded/inactive bindings.
| return { | ||
| facts, | ||
| factSetHash: hashFacts(facts), | ||
| factQueryHash: hashString(`${profile.id}\n${query}`), |
There was a problem hiding this comment.
🟡 Issue: factQueryHash only hashes the static SPARQL text, while snapshotId, view, and scopeUal are applied later in JS. Different resolution scopes can therefore publish the same query hash even though they selected different fact sets. Include the effective filters in the hashed query, or push them into the SPARQL itself.
| }; | ||
| } | ||
|
|
||
| if (!payload || !Array.isArray(payload.facts) || payload.facts.length === 0) { |
There was a problem hiding this comment.
🟡 Issue: this hard-requires a non-empty facts array, so the new snapshot-resolved evaluation path is unreachable from dkg ccl eval even though the agent/API support omitting facts. Allow --snapshot-id/--view/--scope-ual without --case or --facts-file, and only require facts for explicit manual mode.
CCL (Corroboration & Consensus Language) is a deterministic DSL for expressing how a paranet decides whether shared DKG facts are sufficient to support, reject, or promote a claim. We need it so agents and nodes can evaluate the same approved policy over the same snapshot, produce the same result, and turn paranet governance into something replayable, auditable, and domain-specific instead of relying on ad hoc reasoning.
Summary
Adds CCL (Corroboration & Consensus Language) support as a paranet-scoped governance and adjudication layer for the DKG.
CCL is a deterministic policy DSL for defining how a paranet interprets shared DKG facts and decides whether a claim is sufficiently corroborated, contradicted, promotable, or acceptable under its own approved rules. Instead of relying on agent-specific reasoning or informal coordination, CCL lets a paranet define explicit decision rules that every node and agent can evaluate the same way.
This matters because the DKG already provides shared facts, scoped paranets, and publish/finalization flows, but it does not by itself define how a paranet should turn facts into decisions. CCL fills that gap by making adjudication programmable, replayable, and auditable. The intended flow is:
This PR makes that flow concrete by adding policy management, deterministic evaluation, structured result publishing, and owner-only policy approval. It allows each paranet to define its own governance logic while keeping policy execution consistent across agents and nodes.
flowchart TD A[Agent coordination<br/>messages / skill calls] B[Shared DKG facts<br/>claims, supports, contradictions, quorum] C[Approved paranet policy<br/>CCL policy name + version + hash] D[Deterministic evaluation<br/>same policy + same facts = same output] E[Structured result publication<br/>CCLEvaluation / CCLResultEntry / CCLResultArg] F[Paranet governance outcome<br/>accept, reject, promote, or continue review] A --> B B --> D C --> D D --> E E --> FExample Agent Interaction
sequenceDiagram participant A as Agent A participant B as Agent B participant C as Agent C participant DKG as DKG Paranet participant CCL as Approved CCL Policy participant EVAL as CCL Evaluator A->>B: Request verification for claim c1 A->>C: Ask for independent evidence A->>DKG: Publish claim facts for c1 B->>DKG: Publish support evidence e1 C->>DKG: Publish support evidence e2 A->>DKG: Resolve active approved policy DKG-->>A: Return policy reference/version/hash A->>EVAL: Evaluate policy against fixed fact set EVAL->>CCL: Apply deterministic adjudication rules CCL-->>EVAL: Derived facts and decisions EVAL-->>A: propose_accept(c1) A->>DKG: Publish structured evaluation result DKG-->>A: Result available for downstream governance/finalizationIn this flow, agent communication is used only to coordinate evidence gathering. The actual agreement step happens through shared DKG facts plus an approved CCL policy. Because the policy is fixed and the fact set is explicit, every node can replay the same evaluation and arrive at the same outcome.
Changes
Why It Works
Test Plan
Related Issues