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.
CapabilityWhat the entity can technically or physically do.
PermissionWhat local and higher-order policy allows in this context.
ObligationWhat the entity must do when safety or law requires it.
ProhibitionWhat the entity must not do.
IntentWhat 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.
AllowIdentity, capability, policy, and evidence line up sufficiently.
Require GrantAn explicit scoped grant is needed from the appropriate authority.
Require Human ReviewA human needs to inspect the encounter and approve before action continues.
Deny / Not Capable / Not In ScopeThe action is blocked because the capability, policy, or scope is wrong.
Reference suite
LOCOM is a standardizable model, not just an idea.
Core specificationImplementation-grade guidance for interoperable encounter-time exchange.
Ten core artifactsEntityDescriptor, CapabilityCredential, AuthorityPolicy, EncounterIntent, PresentationBundle, EncounterDecision, and related components.
Six profile familiesResidential doorstep, lobby reception, software repository agents, warehouse AMRs, curbside vehicles, and drone dropoff.
Conformance classesCoreArtifactProducer, 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 installsAs workflow packs become more powerful, Picnic needs explicit provenance, authority, and approval behavior.
Runtime decisionsAgents and workflow runners may need to be allowed, denied, granted, or escalated at encounter time.
Human oversightPicnic 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.