GROP — Generic Runtime Operating Protocol

• G2 pins kernel identity to grop:kernel literally: a KS speaking a self-minted heavy 'kernel' does not satisfy native interop (ST-2). Minimality of grop:kernel is enforced by G1b + composite F5-1/F5-3.

• The class of the single canonical generic runtime operating protocol kernel. A Knowledge Space is native-GROP iff it declares grop:speaks grop:kernel (gate G2). The kernel is the minimal shared interaction contract; keeping it minimal (gate G1b) is what makes native coupling near-free.

Use only to type the single canonical kernel node grop:kernel. Never subclass it for a domain-specific 'kernel' and never mint sibling instances: a self-minted kernel fails native interop by construction (ST-2 / gate G2). Domain richness belongs to grop:ConcreteProtocol derivations.

• Closed at three is the minimality boundary. Growing the phase set is how a generic kernel silently becomes a heavy domain protocol; G1b targets by grop:phase presence regardless of the node's class (ST-3).

• An abstract phase of the kernel interaction lifecycle. The phase set is CLOSED at exactly three members (grop:Request, grop:Offer, grop:Commit): the demand -> proposition -> binding lifecycle. Any node carrying a grop:phase outside the triad is kernel bloat (gate G1b).

Concrete protocols map their steps ONTO the triad; they never add Phase instances. A phase designator is a shared specification (BFO generically dependent continuant, sidecar 0.2.0), not a runtime event: the temporal parts of running interactions are typed downstream in session data, never here.

• Every grop:ConcreteProtocol MUST carry prov:wasDerivedFrom grop:kernel (gate G3). Derivation is necessary-not-sufficient: the profile's own interactions must also pass G1b (no non-kernel phase, ST-3). This class is a derivation TARGET declared by the kernel; the kernel holds no edge TO any instance (G4).

• A downstream, contextual operating protocol derived from the kernel per terrain/domain (SEMIC Core -> Application-Profile pattern). Loosely coupled and pluggable; a KS binds to it optionally by resolvable pointer (bra0:operatingModel). ValueFlows is the first such protocol (the value-chain / economic-network profile).

Type downstream protocol SPECIFICATIONS only (e.g. grop:valueflows in protocols/valueflows.ttl); instances live outside this file (G4). A conforming instance carries prov:wasDerivedFrom grop:kernel and keeps its interactions inside the kernel triad.

• No rdfs:domain: the property applies to any interaction node regardless of its (possibly domain-typed) class, so minimality cannot be laundered by re-typing the subject (ST-3).

• Assigns the kernel lifecycle phase of an interaction. The object MUST be one of the closed triad; G1b fires on any node carrying a grop:phase outside {grop:Request, grop:Offer, grop:Commit}, whatever the node's class.

Attach to any interaction node, whatever its class; the object MUST be one of the closed triad. Do not specialize this property to widen the phase set — G1b fires on any grop:phase value outside {Request, Offer, Commit}.

• Own kernel mint: no external vocabulary ships the two-lane context | message separation as an importable RDF primitive (Beckn has it as an OpenAPI pattern; the Holon CG gestures at it without a stable IRI). This is the logged D-F5-1 debt, resolved here. Design-borrow from the Beckn context lane.

• The governing/addressing lane of an interaction: routing, identity, provenance — PII-shielded, kept ORTHOGONAL to the payload. One of the two constitutionally-separated lanes of a kernel interaction.

Governing/addressing lane ONLY: routing, identity, provenance. Payload content never rides this lane; the two lanes are constitutionally orthogonal, which is what keeps the governing side PII-shielded and separately governable.

• Own kernel mint (D-F5-1). Commerce/domain weight can only ride this lane; composite minimality (G1b AND F5-1 AND F5-3) evaluates the payload lane so weight cannot smuggle past phase closure alone (ST-1). Design-borrow from the Beckn message lane.

• The payload lane of an interaction: the substantive content exchanged, kept ORTHOGONAL to the governing/addressing lane. One of the two constitutionally-separated lanes of a kernel interaction.

Payload lane ONLY: the substantive content exchanged. Domain and commerce weight is admissible here (and only here) at the concrete-protocol level; governing/addressing metadata never rides this lane.

• Polarity is expressed at the kernel as a role assignment, carrying no commercial/accounting frame (that belongs to concrete protocols such as ValueFlows).

• Marks the party playing the demand pole of an interaction (the requester side). Abstraction of the Beckn BAP (Beckn Application Platform) role.

Marks the demand pole only. The kernel mints NO role class: the estate-level realisation of the pole is party:PartyRole via the party socle (O-GROP-1 resolved 2026-07-07); buyer/consumer commercial framing belongs to concrete protocols.

• Mirror of grop:demandRole: a kernel-level role assignment with no commercial/accounting frame (provider/seller semantics belong to concrete protocols such as ValueFlows).

• Marks the party playing the offer pole of an interaction (the proposing side). Abstraction of the Beckn BPP (Beckn Provider Platform) role.

Marks the offer pole only. As with the demand pole, the kernel mints NO role class — the estate-level realisation is party:PartyRole via the party socle (O-GROP-1).

• Trust filler only: the kernel names the attestation hook; the credential/proof suite is supplied by the borrowed VC 2.0 layer, not re-minted here.

• Trust carried by attestation rather than a central authority: an interaction (or party) references a verifiable attestation of its claims. Borrows the W3C Verifiable Credentials 2.0 / DID model; binds to the NextGraph attestation socle (Omyn-SECRET).

Names the trust HOOK only: point it at a verifiable attestation. Credential formats, proof suites, revocation and verification logic live in the borrowed VC 2.0 / DID layer, never in the kernel.

• No rdfs:domain naming a KS class: declaring a domain would make the kernel reference a downstream construct (bra0:KnowledgeSpace), breaching cohesion (G4). The KS-side constitutive invariant bra0:speaksProtocol (core/knowledge-space.ttl) is an upward specialization of this predicate (rdfs:subPropertyOf grop:speaks).

• The constitutive membership predicate: a Knowledge Space declares grop:speaks grop:kernel to bind natively to the generic runtime operating protocol. Presence of this binding is enforced as a class-level invariant of every KS (gate G2), a sibling of Offline-First.

Declared BY a Knowledge Space, with grop:kernel as the only legitimate object (G2 pins the value). Do not use it to point at concrete protocols — optional protocol bindings go through the KS-side operatingModel pointer, not through the conformance predicate.