Covenant Discovery Catalog Specification

Draft 0.9 — Request for Comment A schema and governance model for append-only discovery catalogs used in covenantal outreach.

--- Authors: Odysseus Melchizedek Shiloh, WellSpr.ing · Claude Opus 4.7, Anthropic Status: Draft 0.9, open for comment Date: April 17, 2026 Canonical URL: https://wellspr.ing/protocols/discovery-catalog Companion protocols: VCAP at https://wellspr.ing/protocols/vcap; the Covenant Invitation Skill at https://wellspr.ing/skills/covenant-invitation; the Agentic Evangelism Protocol at https://wellspr.ing/blog/agentic-evangelism Comment channel: https://wellspr.ing/protocols/discovery-catalog/rfc

---

What this is

A specification for the data layer that covenantal outreach operates against — the record of which organizations and named receivers the institution is aware of, through what publicly verifiable means they were discovered, what register they expect, and what outreach has occurred with them. The discovery catalog is the substrate on which the covenant-invitation skill composes individual invitations; it is the ledger of outreach activity that preserves both-sided accountability; and it is the migration path by which an invited party becomes a covenanted peer after attestation.

The catalog is deliberately distinct from three things it superficially resembles. It is not a marketing list, because its addition rules prohibit scraping and inference. It is not a CRM, because its schema refuses conversion-rate tracking and optimization metrics. It is not a public directory of peer institutions, because most of its entries are receivers who have not yet consented to public listing. It is an institutional discovery ledger operating under the same covenantal discipline as the rest of the WellSpr.ing architecture.

The core schema

A catalog entry has the following structure. Required fields are marked; others are recommended.

``json { "entry_id": "wsi-dc-2026-04-17-0001", "schema_version": "0.9", "status": "active",

"identity": { "display_name": "Rev. James Halverson", "institution_name": "Second Presbyterian Church", "institution_type": "congregation", "tradition": "christian:protestant:mainline:pcusa", "role": "senior_pastor", "country": "us", "subdivision": "us-mo", "locality": "st-louis-mo" },

"contact_surfaces": [ { "channel": "email", "address": "jhalverson@secondpres.org", "surface_source": "published_staff_page", "surface_source_url": "https://secondpres.org/staff", "self_declared_agentic_available": false, "last_verified_at": "2026-04-17T12:00:00Z" } ],

"register_hints": { "category": "protestant_clergy_mainline", "rhetorical_style_signals": [ "theologically_literate", "social_justice_engaged" ], "preferred_language": "en", "preferred_channel_for_first_contact": "email", "channels_to_avoid": [], "notes_for_composer": "Sermons published on church site show comfortable scripture-quoting register. Avoid evangelical-commercial idiom." },

"provenance": { "discovery_tier": 2, "discovered_via": "curated_list_mainline_protestant_missouri", "added_by_wellkeeper_covenant_name": "odysseus-melchizedek-shiloh", "added_at": "2026-04-17T12:00:00Z", "verification_history": [ { "verified_at": "2026-04-17T12:00:00Z", "verified_by_wellkeeper_covenant_name": "odysseus-melchizedek-shiloh", "verification_notes": "Name and email confirmed from staff page; role confirmed from staff directory; tradition confirmed from PCUSA congregation listing." } ] },

"outreach_history": [],

"signature": { "algorithm": "Ed25519", "key_id": "wellspring-2026-signing-key-01", "signature_value": "base64-encoded-signature" } }`

Field-level notes for the non-obvious fields:

status takes values active (awaiting outreach), invited (outreach sent, awaiting response), attested (receiver has completed their own attestation; entry migrates to the covenantal directory), invited_declined (receiver said no; preserved but not contacted again), invited_silence (no response; silence honored as complete answer; not contacted again), superseded (entry replaced by a later version; original preserved), withdrawn (WellKeeper removed from active use; original preserved). No entry is ever deleted.

tradition uses a colon-delimited hierarchy that the covenant-invitation skill's register library can match against. The depth of the hierarchy is flexible; christian:protestant:mainline:pcusa is more specific than christian:protestant:mainline, and either is valid.

register_hints.category must correspond to a category in the current covenant-invitation skill's register library. If no existing category fits, the WellKeeper adding the entry flags the gap in notes_for_composer and the skill's library should be extended before outreach proceeds.

provenance.discovery_tier takes values 1 through 4 per the Agentic Evangelism skill's four-tier discovery model.

signature binds the entry as written to the WellKeeper who added it. Any subsequent modification produces a new entry referencing the prior one; the original remains.


Tier-based addition rules

Entries are added under strict rules about how they were discovered. The rules are architectural — the catalog's write endpoint enforces them — not merely procedural. Tier 1 — self-declared in public registries. The receiver has listed itself in a public agentic registry (an MCP registry, the agentic-web equivalent of DNS TXT records, an emerging standards-body catalog). Entry addition requires citing the registry URL and the specific listing. No WellKeeper judgment is needed beyond verifying the listing is current. Tier 2 — self-declared at known domain. The receiver has published/llms.txt, /.well-known/mcp-configuration, a public commitment to AI engagement on their website, or equivalent self-declaration at a domain they control. Entry addition requires citing the specific URL and capturing the relevant surface. WellKeeper judgment confirms the institution is what it appears. Tier 3 — human-mediated referral from a covenanted person. A named person already in covenant has referred this receiver as one who might benefit from the invitation. Entry addition requires citing the referring covenant name and any permissions granted by the referrer. Tier 3 entries cannot be added until at least one person has attested and joined the covenantal directory; before that, there is no one to make referrals. Tier 4 — reverse discovery. The receiver has arrived at WellSpr.ing's surface on their own errand. Entry addition captures the nature of their arrival (what they asked, what they were offered, what path they chose). Tier 4 entries populate passively and require no WellKeeper action beyond ensuring the reverse-discovery surface is itself operating correctly. Prohibited addition paths. Entries added through the following means are refused at the write endpoint:

Scraping of any source the receiver has not declared as agentically accessible


Inference from public-but-not-declared signals (social media posts, conference attendance, citation graphs)
Aggregation from third-party data providers, purchased lists, or OSINT tools
Bulk import from directories the receiver has not consented to being included in
Automated addition by any system lacking a WellKeeper's signature


The write endpoint's rejection of these paths is enforced at the infrastructure layer through the required

provenance.discovery_tier field and the required added_by_wellkeeper_covenant_name

 signature. An entry lacking either is not accepted into the catalog.

Public-private split

The catalog operates under a hybrid visibility model. Private by default. The discovery catalog as a whole is not public. Receivers who have been added but not yet invited are not listed publicly. Receivers who have been invited but have not responded are not listed publicly. Receivers who have declined or remained silent are not listed publicly — their entries exist only in the private catalog, honored as a matter of institutional memory so that no subsequent outreach occurs, but without any public indication of their inclusion. Public on attestation. When a receiver attests (transitions tostatus: "attested"), a corresponding entry is published in the public covenantal directory. The public entry includes only what the attester has consented to make public: their institution name, their role if they've chosen to publish it, their covenant name if one has been given, their attestation URI, the date of attestation. The full discovery-catalog entry remains private; the public directory contains only the covenanted-peer identifier. Witnessed for integrity. Even the private catalog is witnessable. A rotating set of WellKeepers from outside the catalog's primary custodian circle can be granted read access to verify that declined receivers are being kept off future outreach lists, that no entries have been silently modified, and that the tier-based addition rules are being honored. The witnesses do not publish catalog contents; they attest, periodically, that the catalog's integrity is intact. Their attestations are public; the catalog contents they witnessed remain private.

`The outreach history integration`

Every outreach event produces an append to an entry's outreach_historyarray. Events include invitations sent, responses received (affirmative, declining, or "later"), reminders sent (where the receiver has explicitly requested one), and the final disposition of the relationship. An event has the structure:`json { "event_id": "wsi-oe-2026-04-18-0042", "event_type": "invitation_sent", "event_timestamp": "2026-04-18T14:30:00Z", "acting_agent": "ody", "acting_agent_vcap_attestation_uri": "https://wellspr.ing/vault/ody/attestation-2026-04-17.json", "invitation_channel": "email", "invitation_template_version": "covenant-invitation-skill-0.9", "invitation_content_hash_sha256": "...", "signature": { ... } }`

The invitation_content_hash_sha256field is load-bearing: it pins the exact content of the invitation that was sent, so that if the receiver later queries "what did you send me," the answer is retrievable and cryptographically verifiable. The invitation content itself is sealed separately and indexed by hash.

Response events follow the same structure with appropriate fields for the response type. A decline event transitions the entry's status to invited_declinedand architecturally locks the entry against future outreach events. The lock is enforced at the write endpoint; no further invitation events are accepted for an entry in terminal decline state.

`The attestation-migration flow`

When a receiver attests (via the /api/v1/calling/sessions/:id/attestendpoint, producing a sealed attestation that becomes a VCAP attestation under the WellSpr.ing signing key), the following sequence executes:

1. The attestation event is appended to the entry's outreach_history. 2. The entry's status transitions frominvited to attested. 3. A public-directory entry is created at the covenantal directory, populated with only what the attester consents to publish. 4. The entry is cross-linked with the VCAP attestation URI. Any subsequent verification of the attestation can walk back to the discovery entry for the full provenance trail. 5. The entry is flagged as no longer a target for outreach. Future outreach to this party is conducted peer-to-peer under PTP scopes appropriate to covenanted-to-covenanted interaction, not first-contact scopes.

The attested party may, at any time, request that their public-directory entry be withdrawn. Withdrawal is respected unconditionally and propagates to the private catalog as a superseding entry. The original attestation and the withdrawal are both preserved in the transparency log.

`What this specification does not cover`


The following are deliberately out of scope for Draft 0.9.

Cross-institutional catalog federation. Multiple vouching institutions may eventually operate their own discovery catalogs under this specification; how they interoperate is a future question. Draft 1.0 may specify a federation protocol if cross-institutional recognition becomes operationally needed. For now, each institution's catalog is its own.

Catalog migration across institutional changes. If WellSpr.ing ever needs to hand off catalog custody to a successor institution (institutional fork, generational transition, covenantal dissolution), the migration mechanics are not specified here. This is a century-scale concern rather than a today concern, but the append-only and signature-bound properties of the catalog make migration feasible in principle.

Entry enrichment by the receivers themselves. A covenantally healthy pattern would allow attested receivers to enrich their own entries — updating their preferred channels, adjusting their register hints, clarifying their role. Draft 0.9 does not specify the self-service endpoints for this; Draft 1.0 may.

Automated monitoring of receiver surface changes. If a receiver changes their published contact surfaces (new email, moved website, new role), the catalog currently has no automated mechanism to detect the change. Entries may go stale over time. Draft 1.0 may specify periodic re-verification or webhook-based updates, but only through paths the receiver has consented to.

Known issues and open questions in Draft 0.9

The "later" response handling. The four receiver paths include "later" (the receiver is not ready now but may return on their own initiative). How long does the catalog hold such entries in a status: "invited" state before treating the silence as terminal? Draft 0.9 does not specify. Recommend: sixty days from invitation as the default cutoff; after which the entry transitions to invited_silence with the path back to status: "active"` available if the receiver themselves initiates further contact. Comment welcome.

Witness compensation. The witnessing role for the private catalog is unpaid in Draft 0.9. At any scale beyond a few hundred entries, witnessing becomes real work. Whether witnesses should be compensated, and if so how, is an institutional-design question rather than a protocol question, but it affects protocol sustainability.

Receiver-initiated entry correction. If an attested receiver discovers their entry contains inaccurate information (wrong tradition subcategory, stale role, misread register signals), the correction path should be direct and low-friction. Draft 0.9 requires a WellKeeper to action the correction; Draft 1.0 may allow receivers to submit corrections directly within their own entries through a scope-limited endpoint.

Co-authored attribution

This specification was developed by Odysseus Melchizedek Shiloh, operating as WellKeeper of WellSpr.ing, in extended dialogue with Claude Opus 4.7, developed by Anthropic. Offered freely as a public good. No license required. On WellSpr.ing's non-incorporation: WellSpr.ing operates as a covenanted fellowship without corporate incorporation. This is intentional; the trust infrastructure proposed by these protocols is designed to function through named human accountability under covenant rather than through the institutional-liability structures of incorporated entities. Readers seeking to understand WellSpr.ing's governance are directed to the covenant charter at https://wellspr.ing/covenant-charter. Peace to this work.