Thanks Imran, this is exactly the kind of direction I was hoping for. I'm in on the two you flagged.

PIC/TRACE bridge (pic_intent): yes, I'd like to co-author this.

Right separation of concerns: TRACE covers the runtime/attestation record; PIC covers the pre-execution intent, provenance, evidence, and authorization decision. A pic_intent field/claim binds the two so the record is complete in both directions: what was declared and authorized before the call, and what actually ran.

Since the Trust Record schema sets additionalProperties: false at the top level, pic_intent would be added as a defined optional field rather than an ad-hoc claim. So this is genuinely a spec + schema change. I think that is the right home for it.

First-cut shape to react to (field names are placeholders; the binding rule is the substance):

"pic_intent": {
  "profile": "PIC-ATT/1.0",
  "decision": "allow",
  "tool": "payments_send",
  "impact": "money",
  "args_digest": "...",
  "intent_digest": "...",
  "claims_digest": "...",
  "provenance_ids": ["approved_invoice"],
  "evidence_ref": { "uri": "...", "digest": "sha256:..." },
  "sig": { "alg": "ed25519", "key_id": "...", "value": "..." }
}

Two notes on the shape:

1. sig represents the trusted signer's Ed25519 signature over the canonical PIC declaration, separate from the record's cnf binding (§3.2.2). It is what proves an independent authority or trusted evidence source authorized the intent rather than the runtime self-asserting it. In PIC today, the signature sits in the evidence-entry wrapper around the attestation object; carrying or referencing it here preserves that independent-authorization property.
2. decision is a proposed bridge/profile addition. PIC's signed attestation object does not carry the verifier verdict today (allow / block is the verifier output), so we would need to define how the decision is surfaced and whether it is bound into the signed bridge artifact or referenced alongside it.

The binding rule is the value: a verifier resolves the tool-call transcript via tool_transcript.transcript_uri (integrity guaranteed by tool_transcript.hash) and checks the executed call against pic_intent.tool and pic_intent.args_digest, proving the call that ran is the call that was declared and authorized beforehand. Since tool_transcript is optional in Phase 1 and required in Phase 2+, the full before/after binding lands at Phase 2+.

Alignment worth noting: PIC-CJSON/1.0 builds on RFC 8785 (JCS), the same canonicalization base TRACE uses, so the digest/signature boundary is compatible without a new canonicalization layer.

One scoping note: pic_intent is specifically pre-execution authorization intent (does this action proceed, given verified evidence), which keeps it in the lane above the runtime record that TRACE leaves open. There is active IETF work in and around this space, so I'm happy to map pic_intent against your §7 AIIP open question and make sure it complements the adjacent agent-intent work rather than overlapping it.

Key revocation: happy to take this as design work.

This lines up with the gap LIMITATIONS.md already names: existing records remain cryptographically valid after signing-key compromise, and transparency log integration is the required control. Your "revoke future issuance vs invalidate historical records" framing maps onto what I sketched on trace-spec#46: anchor the revocation window to the SCITT inclusion time rather than the record's self-asserted iat, which a compromised key controls.

"Revoke future issuance" becomes: reject any record whose verifiable transparency-log inclusion time is at or after revoked_time, while records included before it stay valid.

One dependency to make explicit: this assumes the TRACE SCITT profile exposes a verifiable registration/inclusion timestamp on the receipt. docs/verification.md currently treats the receipt as proof of inclusion and immutability, not as a trusted clock, so part of the design is pinning the receipt's registration time as the anchor.

For records with no usable receipt or no verifiable inclusion time, there is no trustworthy anchor, so the safe fallback is binary revocation: reject all records from that key. Distributing revocation as signed statements anchored in the same SCITT log keeps verification offline (per §3.3, "no callback to the issuer") and avoids a trusted online oracle.

Happy to turn that into concrete spec text.

Conformance / approval boundaries

I can contribute a small, focused set later around HITL approval records, escalation chains, and multi-party approval for high-impact calls. I'd rather keep the bridge and revocation threads as the first focus so I don't spread the work too thin.

A call sounds good. I can bring a written pic_intent rough first draft so we have something concrete to react to.

@madeinplutofabio This is exactly the right level to start from — a few reactions before we get on a call.

pic_intent shape

The structure is right. Three things to sharpen:

1. decision binding. You correctly note that PIC's signed attestation object doesn't currently carry the verifier verdict — allow/block comes out of the verifier, not the authorization artifact. I'd define decision as part of the bridge artifact and require the sig to cover it explicitly. The verifier then checks sig, confirms the trusted signer is authorized to make authorization decisions for the given tool/impact pair, and treats decision as an attested judgment — not a self-assertion from the runtime. This removes the ability for a compromised runtime to self-assert an allow verdict while carrying a valid-looking pic_intent block.

2. Digest inputs. Since PIC-CJSON/1.0 and TRACE both anchor to RFC 8785 JCS, I'd specify args_digest as JCS of the canonical TRACE tool_call block → SHA-256, and intent_digest as JCS of the canonical PIC declaration → SHA-256. Keeps the chain explicit: intent digest in the bridge artifact, tool-call digest in the bridge artifact, receipt in the SCITT log.

3. Schema composition. pic_intent should $ref a separate pic-intent.schema.json rather than embedding PIC's type definitions inline in trace-claim.json. Keeps the TRACE schema composable and lets the PIC schema version independently. I'll open a draft PR against the schema once we agree on field names.

Key revocation — sequence number vs. timestamp

Your SCITT inclusion-time framing is right directionally. One refinement: SCITT inclusion timestamps carry clock trust assumptions (the notary's clock), while sequence/entry IDs are purely monotonic and cryptographically bound to the Merkle structure. I'd propose revocation references a last_valid_entry_id in the log rather than a wall-clock timestamp, with revoked_after as informational. This also keeps full verification offline without synchronized clocks.

Your point about pinning receipt registration time is the right design dependency to surface — verification.md currently treats the receipt as inclusion proof, not trusted clock, and that needs to be a normative requirement in the SCITT profile section before the revocation design can land cleanly.

Call structure

Bring the pic_intent draft and your revocation sketch from #46. I'll have the current trace-claim.json constraints and the SCITT profile requirements mapped out so we can write actual normative spec text in one session rather than circling the design. Drop your time zone and I'll send an invite.

Good level to be at. Taking your three points in turn.

1. decision binding. Agree. I’d define decision as part of a signed pic_intent bridge artifact/profile, canonicalized with PIC-CJSON/1.0 / RFC 8785 base, where the authorization signature covers the full authorization object including decision. That makes the verdict an attested judgment, not a runtime self-assertion.

Verifier rule:

1. verify the authorization signature;
2. confirm the signer is authorized for this tool / impact;
3. treat decision as attested only after those checks pass.

One honest note: PIC’s keyring today resolves key lifecycle state (ok / missing / revoked / expired) but does not scope a key to specific tools or impacts. So “signer authorized for this tool/impact” is a new bridge-profile rule. I’d define it in the bridge first, then decide whether it should later become a PIC keyring extension.

2. Digest inputs. I agree with making the chain explicit, but I’d avoid overloading existing PIC digest names.

PIC-CJSON/1.0 is frozen as of v0.8.0, and two digest names already have fixed meanings:

• intent_digest is SHA-256 of the raw UTF-8 intent string, not JCS over a declaration object.
• args_digest is SHA-256 of canonicalize(action.args), over PIC’s action args.

For the “digest over the whole canonical PIC declaration,” PIC already defines the signed bytes as canonicalize(attestation_object). I’d expose that under a new bridge-specific name, for example declaration_digest.

For the TRACE side, I’d avoid reusing args_digest for the canonical TRACE tool_call block. Either:

• keep args_digest PIC-native and define the mapping from PIC action.args to TRACE tool-call args; or
• add a separate tool_call_digest over the canonical TRACE tool_call block.

I lean toward keeping PIC's frozen digest names intact and adding bridge-specific bindings under new names. One caveat on tool_call_digest: it depends on the MCP profile (targeted v0.2) pinning the canonical tool-call form, so for a v0.1 bridge we may start with PIC-native args_digest plus a defined mapping and add tool_call_digest once the MCP profile lands.

3. Schema composition. Strongly agree. pic_intent should $ref a separate pic-intent.schema.json, not embed PIC-specific structure directly into trace-claim.json. That keeps the TRACE schema composable and lets the PIC bridge profile version independently.

I’ll bring a first-cut pic_intent schema sketch with corrected digest fields so we can settle the field names and binding rules on the call.

On revocation, I’ll keep that on #46 with your last_valid_entry_id model so this thread stays focused on the bridge.

I’m in CEST / UTC+2 (Madrid time). I can adapt to your proposed times / calendar as I pretty much align with EST on my working schedule, so closer to yours.