Intent Match Status Scheme

Publisher: Global.Church · Created: 2026-05-14 · 5 concepts

https://ontology.global.church/core#IntentMatchStatusScheme

A controlled vocabulary classifying the status of a non-binding match between a Need and an Offering. The five concepts capture the full lifecycle from initial pairing (Proposed) through compatibility scoring (Scored), to terminal states (Rejected, Stale) or to gateway state (Accepted) that formalizes through a gc:Agreement.

Code	Label	Definition
`IMS-ACC`	Accepted	Gateway state — both parties have consented to the match and a follow-up gc:Agreement is expected to formalize the alignment. SHACL :IntentMatchShape raises sh:Violation if a match is in this state but no gc:Agreement carries gc:formalizesMatch pointing back at it: Accepted is meant to be a transient state on the path to formalization, not a terminal posture. The Agreement, once authored, references the IntentMatch via gc:formalizesMatch and creates one or more gc:FulfillmentCommitment instances to carry the obligations forward.
`IMS-PRO`	Proposed	Initial state — the match has been surfaced (manually by a coordinator or programmatically by a matching agent) but has not yet been evaluated for compatibility. SHACL :IntentMatchShape raises sh:Warning on this state to signal that downstream consumers should treat the match as low-signal until scored. Transitions: → Scored (compatibility evaluated), → Stale (no engagement), → Rejected (one party declines without scoring).
`IMS-REJ`	Rejected	Terminal state — at least one party has declined the match. The IntentMatch instance is preserved for audit and learning (matches that get rejected feed scoring-model improvement) but no Agreement is generated. The underlying Need and Offering remain active and may be matched against other counterparts.
`IMS-SCR`	Scored	The match has been evaluated for compatibility — a gc:matchScore (xsd:double) and optional gc:matchReason (xsd:string) have been written to the IntentMatch instance. The match is now actionable: a coordinator can present it to the parties, or an agent can route it for acceptance/rejection. Transitions: → Accepted (both parties consent), → Rejected (one party declines), → Stale (parties take no action).
`IMS-STA`	Stale	Terminal state — the match has aged past its actionable window without engagement. Distinct from Rejected: no party has actively declined, the match has simply lapsed. The IntentMatch instance is preserved for audit. Stale-rate is itself a useful federation metric (high stale-rates suggest unactionable scoring or attentional failure).