LOCOM The encounter layer for trust, authority, and human-readable decisions

Independent standard

LOCOM is not a product feature. It is a shared encounter grammar for trust.

LOCOM standardizes the encounter layer: the structured claims, policies, and decisions needed whenever a human, organization, software agent, robot, vehicle, drone, or controlled space wants to act in context.

Actor × Action × Target × Context -> Decision

It is designed to answer five practical questions before action: who is this, who controls it and who is responsible, what can it do, what may it do here and now, and what evidence backs the answer. Picnic happens to be one user and implementation surface for LOCOM. LOCOM itself is broader than Picnic.

Read the core model See implementation use

The five questions

LOCOM starts with practical inspection, not vague trust.

The model standardizes the questions a verifier or operator needs answered before letting an entity act in a real context.

Who is this?Identity is explicit, not implied.

Who controls it?Control and responsibility stay visible.

What can it do?Capability is separate from permission.

What may it do here?Authority is contextual and scoped.

What evidence backs that up?Claims need supporting proof.

Core model

LOCOM separates what an entity can do from what it may do.

Capability

What the entity can technically or physically do.

Permission

What local and higher-order policy allows in this context.

Obligation

What the entity must do when safety or law requires it.

Prohibition

What the entity must not do.

Intent

What the entity says it wants to do right now. Intent never creates authority on its own.

Decision outputs

Trust is progressive, not binary.

Not every encounter needs the same evaluation depth. LOCOM supports decision types that make escalation and oversight explicit.

Allow

Identity, capability, policy, and evidence line up sufficiently.

Require Grant

An explicit scoped grant is needed from the appropriate authority.

Require Human Review

A human needs to inspect the encounter and approve before action continues.

Deny / Not Capable / Not In Scope

The action is blocked because the capability, policy, or scope is wrong.

Reference suite

LOCOM is a standardizable model, not just an idea.

Core specification

Implementation-grade guidance for interoperable encounter-time exchange.

Ten core artifacts

EntityDescriptor, CapabilityCredential, AuthorityPolicy, EncounterIntent, PresentationBundle, EncounterDecision, and related components.

Six profile families

Residential doorstep, lobby reception, software repository agents, warehouse AMRs, curbside vehicles, and drone dropoff.

Conformance classes

CoreArtifactProducer, BundleProducer, PolicyDecisionPoint, Verifier, HumanCardRenderer, PrivacyRespectingVerifier.

How Picnic relates

Picnic uses LOCOM. LOCOM is not owned by Picnic.

Picnic is one product context where LOCOM becomes useful: workflows, agents, installations, cross-project permissions, runtime approvals, and human-readable trust cards. That makes Picnic a user of LOCOM, not the definition of LOCOM.

Workflow installs

As workflow packs become more powerful, Picnic needs explicit provenance, authority, and approval behavior.

Runtime decisions

Agents and workflow runners may need to be allowed, denied, granted, or escalated at encounter time.

Human oversight

Picnic can render human-readable cards, decision logs, and review prompts, but those are implementations of the broader standard.

For builders

The next question is not “can this thing act?” It is “under what profile, with what proof, and under whose authority?”

That is the strategic value of LOCOM. It gives builders a shared grammar for trust across digital and physical encounters, with enough structure to support machine-readable evaluation and enough plain language to remain legible to humans.