Hi

Thanks for the update. It helps.

You are right about community and governance, but we also need at least a
"perspective" on code.
So, even if there's no/tiny code for now, we need more than specs.

I will take a look at the GitHub repo you mentioned.

Regards
JB

On Sun, Apr 5, 2026 at 5:22 AM Fabio Salvadori <[email protected]>
wrote:

> Hi JB,
> Thank you, I really appreciate the reply. I actually found it by chance in
> the public archive while searching, so apologies for the delayed response.
> I’m subscribing to [email protected] [mailto:
> [email protected]] so I don’t miss follow-ups on-list ( I hope
> :) ).
> A short summary of PIC as it exists today:
> PIC is not an agent framework. It is a local-first verification / control
> layer that sits between an AI agent and a sensitive tool action.
> Before a high-impact tool call is allowed to execute, the agent has to
> emit a structured proposal describing:
> * what it wants to do
> * why
> * what the impact level is
> * what provenance and evidence support the action
> * which exact tool/action is being requested
> PIC then verifies that proposal against policy and tool binding rules and
> fails closed if requirements are not met.
> So the core purpose is not better prompting, but safer action
> execution: an agent may propose an action, but it should not be able to
> execute a high-impact one just because the model said so.
> A few properties that may help clarify the intent:
> * local-first / no required cloud dependency
> * framework-agnostic by design
> * explicit evidence verification support
> * fail-closed behavior at the action boundary
> * integrations/adapters around environments such as LangGraph, MCP,
> OpenClaw, and Cordum
> One design direction I care about a lot is reducing reliance on
> self-asserted trust from the model side. Recent work in the project has
> moved more toward sanitizing inbound trust and treating trust as something
> that should be verifier-derived / evidence-backed rather than simply
> declared by an agent.
> On community: today it is still early and mostly maintainer-led. The
> current public state is a spec, reference implementation, tests, docs, and
> integrations, but I fully agree that the real Apache question is whether a
> broader open community can form around the problem area.
> The community I would hope to grow is not just users of one library, but
> people interested in secure tool execution for agents, policy /
> verification layers for high-impact actions, interoperable open
> infrastructure for trustworthy agent behavior, independent implementations
> and conformance work over time.
>
> So I’m not assuming PIC is incubation-ready today. I’m mainly trying to
> understand whether the problem space and project shape feel directionally
> compatible with Apache, and what would need to be true for it to become a
> credible candidate.
> Happy to discuss further, and happy also to send a short follow-up
> describing what PIC is not, how I see it relative to existing Apache
> efforts, and what I think would make it more incubation-ready.
> Thanks again for taking a look. I'm really looking forward to hear from
> you.
> Best ,
>
> Fabio
>
> On 2026/03/28 05:27:47 Jean-Baptiste Onofré wrote:
> > Hi Fabio
> >
> > I'm not sure I understand the project yet (I have to read the md on the
> > repo).
> >
> > There's no problem to have a "not ready yet" project in incubation. The
> > focus is both to move forward on the project and grow the community.
> > There's also no problem to have an existing project pretty close to what
> > you are proposing, as long as projects have their own community.
> >
> > Let me take a look and I would be happy to chat with you to better
> > understand the purposes of PiC and evaluate what is the community
> > today/future.
> >
> > Regards
> > JB
> >
> >
> > On Fri, Mar 27, 2026 at 8:43 PM Fabio Salvadori
> > wrote:
> >
> > > Hello Apache Incubator community,
> > > I’m reaching out to get early feedback on whether PIC Standard might
> be a
> > > plausible future candidate for incubation.
> > > PIC Standard is an Apache-2.0 licensed open-source protocol for
> requiring
> > > verifiable provenance, intent, and evidence before AI agents perform
> > > high-impact tool actions. The aim is to provide a vendor-neutral,
> > > framework-agnostic safety layer that makes sensitive agent behavior
> more
> > > auditable and harder to subvert.
> > > The project currently includes a specification, reference tooling,
> tests,
> > > and early integrations, and is being developed in the open here:
> > >
> > > https://github.com/madeinplutofabio/pic-standard
> > > I understand Apache’s incubation process is centered on community
> health
> > > and open governance rather than code alone. With that in mind, I’m not
> > > claiming the project is necessarily ready today. I’m writing to ask:
> > > * Does this sound directionally like something that could fit Apache
> > > incubation?
> > > * Does it appear complementary to existing Apache efforts, or too
> close to
> > > something already present?
> > > * Would any IPMC members be open to offering early guidance on what
> would
> > > make a project like this more incubation-ready?
> > > I’d appreciate any candid feedback.
> > > Best regards,
> > > Fabio Marcello Salvadori
> > > [2b8d1d7b-87b6-455a-9e9f-ae306c29581e]
> >
> [194def61-5b5b-441b-9dcc-992f8cd923d6]

Reply via email to