Produced 2026-05-24 by CC. Source: local clone at /Users/dunin7/foray-protocol-db/ at commit 5f06eea on main, cross-checked against live foraychallenge.dunin7.com (HTTP 200, identical content to local clone). The repository is the upstream of the live site — the live page is the canonical file in docs/foray_challenge_index.html served via a Flask app on the Mac Mini.
This document grounds Claude.ai's understanding of FORAY integration patterns through the material the challenge site presents. Companion to the protocol-level deep-read at /Users/dunin7/Downloads/foray-protocol-deep-read-v0_1.md.
Important framing finding up-front: the challenge site is NOT an integration-pattern catalogue. It is the protocol-validation tool — a public test harness where visitors describe a transaction and an LLM decomposes it into 4A to prove the grammar holds. The integration-pattern story that the kickoff anticipated is not the shape of the material. What the material does surface is a library of 1,000+ canonical transaction types organised by 22 named decomposition patterns. The kickoff's questions about integration interfaces, calling shapes, sync-vs-async behaviour, and per-use-case SDK calls have no direct answer here — those live in the foray-kaspathon repo (covered in the protocol deep-read) or are genuinely undocumented. Where the kickoff's questions cannot be answered from challenge material, I say so honestly.
The Loomworks-shaped use case is identified at §6: "Emergent Agent Transaction" (Library entry #472), in the Autonomous cluster, tagged AGENT-ID + SCALE-INV — with the deeper structural parallel being the AGENT-ID pattern itself across the four Autonomous-cluster entries (#232, #464, #470, #472).
| File / URL | Source | Size | Read for |
|---|---|---|---|
| /Users/dunin7/foray-protocol-db/docs/foray_challenge_index.html | Local clone | 528 lines | Topic 1 (challenge page structure), site architecture |
| /Users/dunin7/foray-protocol-db/docs/foray_library_index.html | Local clone | 1,012 lines | All topics — primary library + pattern legend |
| /Users/dunin7/foray-protocol-db/docs/foray_about.html | Local clone | 115 lines | Topic 7 (project framing) + community state |
| /Users/dunin7/foray-protocol-db/docs/foray_challenge_server.py | Local clone | 803 lines | Topic 3 (server endpoints), decomposition prompt |
| /Users/dunin7/foray-protocol-db/README.md | Local clone | 18 KB | Project framing |
| /Users/dunin7/foray-protocol-db/RFC-0001.md | Local clone | 174 lines | Topic 7 (what the challenge invites) |
| /Users/dunin7/foray-protocol-db/CLAUDE.md | Local clone | ~9 KB | Site architecture (Mac Mini deployment) |
| /Users/dunin7/foray-protocol-db/SCHEMA.md | Local clone | 257 lines | Topic 3 (submission envelope) |
| /Users/dunin7/foray-protocol-db/docs/DUNIN7_FORAY_Schema_Reference.md | Local clone | 621 lines | Cross-reference (already read in protocol deep-read) |
| https://foraychallenge.dunin7.com/ (root) | Live fetch | HTTP 200, 16 KB | Verify live = local (identical) |
| https://foraychallenge.dunin7.com/library | Live fetch | HTTP 200, 70 KB | Verify live = local (identical) |
Source cross-check: the live site returns content byte-identical to the local clone for both pages tested. The local clone is the canonical artifact (per CLAUDE.md the Mac Mini pulls from this repo). Reading the clone is reading the site.
The challenge site presents three pages:
| Page | URL | What it is | What it is not |
|---|---|---|---|
| Challenge | / | Interactive 4A-decomposition test harness — type a transaction, get a structured decomposition | Not a use-case catalogue. Not a list of integration examples. |
| Library | /library | Browsable taxonomy of 1,001 transaction types across 80+ clusters, each tagged with status (Clean / Watch / Flaw) and 2 pattern codes. Click a row → server generates a fresh decomposition via LLM | Not pre-decomposed. The decompositions are produced on demand. |
| About | /about | Project background: 45-year-conception, one-month-build origin story, claim and community status | No integration material. |
The "use cases" in the way the kickoff anticipates them (system-X-integrating-FORAY narratives) do not appear. What appears instead is:
AGENT-ID, WATERFALL, PARALLEL, CHAIN-ATT, APPEND-ONLY, etc.) that mark recurring structural shapes across the library. These ARE the closest thing to integration patterns on the site.To answer the kickoff's "what kind of system is integrating, what data does it construct, what does it send to FORAY" the relevant material is in the foray-kaspathon adapter code (quickbooks-adapter.js, salesforce-adapter.js) — not on this site. I treat that gap honestly in the relevant sections below.
Because the site does not present use cases in the kickoff's sense, the structural integration-pattern picture has to come from the Library's pattern-code system. There are 22 named patterns, reproduced verbatim from foray_library_index.html lines 250-271:
| Code | Description |
|---|---|
| BAND | Floor Accrual always builds + conditional ceiling Accrual activates above threshold |
| WATERFALL | Multi-tier conditional activation — each tier activates only after prior is satisfied |
| PARALLEL | Multiple independent Accruals running concurrently, each against a different basis |
| RESET | Accrual recalculates continuously against a changing oracle — daily, hourly, per event |
| DYN-GOV-REF | Governing reference that changes in value continuously — biological growth, time decay |
| APPEND-ONLY | Protocol boundary — resolution requires new transaction with parent reference, not modification |
| COND-ACT | Accrual only begins building when a condition is met |
| COND-DEACT | Accrual stops building (suspends) when a condition is met — may resume |
| NON-MONO | Accrual changes direction — builds then reduces, or positive then negative |
| REVERSE-DIR | Accrual flows opposite to the conventional direction for that instrument |
| EXEC-ORACLE | Accrual value not known until execution — determined at the moment the Action occurs |
| COMP-CONTINGENT | Competing resolution paths — only one becomes an Action, the other retires |
| MULTI-PARTY | Proportional Accruals across multiple parties simultaneously |
| OPEN-REC | Receiving party unknown at Arrangement creation — placeholder used |
| AGENT-ID | Agent acts on behalf of principal — principal is always the Arrangement party |
| DIRECTING-AUTH | A third party governs transaction terms without being a transfer party |
| PARENT-REF | Transaction references a prior transaction — the chain is the resolution mechanism |
| SUNK-COST | Sunk Cost Settlement — new transaction references original; incurred costs are the oracle |
| GATE-ATT | Attestation gates Accrual activation — remove the Attestation, Accrual does not activate |
| CHAIN-ATT | Attestation chain — each link certifies the next; missing link breaks provenance |
| MIN-CONFIG | Minimum valid configuration — not all four components present; that is correct |
| SCALE-INV | Scale invariance — same grammar structure at £50 or £50 billion |
Why these matter for integration design: any calling system integrating FORAY must classify its native transactions into one or more of these patterns. The pattern determines how the source-system events map into 4A components. For a knowledge-substrate-style integration like Loomworks, the relevant patterns are AGENT-ID (every Companion-mediated transaction), CHAIN-ATT (provenance walks through multiple attestors), PARENT-REF (engagement events reference prior engagement events), and APPEND-ONLY (Memory non-erasure aligns with this exactly).
The library tags every transaction with one of three statuses (reproduced from the same file's tooltip definitions):
The "Flaw" label is critical: the site is explicit that Flaw entries are not protocol failures. They are boundaries — transactions where the resolution mechanism is a parent-referenced new submission, not an in-place modification. Loomworks' Memory non-erasure rule (R-A28) is structurally identical to this boundary mechanism.
The library is 1,001 transactions long. Rendering all of them would be noise. The entries that matter for understanding FORAY's integration shape for a system like Loomworks fall into four groups:
AGENT-ID)These are the entries that explicitly model AI/algorithmic agents producing transactions on behalf of principals. This is the closest cluster to Loomworks' structural shape.
| # | Name | Cluster | Status | Patterns |
|---|---|---|---|---|
| 232 | AI Agent Autonomous Procurement | Autonomous | Clean | AGENT-ID, EXEC-ORACLE |
| 464 | Autonomous Procurement Below Threshold | Autonomous | Clean | AGENT-ID, EXEC-ORACLE |
| 470 | Smart Contract Code-Triggered Payment | Autonomous | Clean | AGENT-ID, MIN-CONFIG |
| 472 | Emergent Agent Transaction | Autonomous | Clean | AGENT-ID, SCALE-INV |
The AGENT-ID pattern (from the legend): "Agent acts on behalf of principal — principal is always the Arrangement party." The decomposition discipline is:
This is reproduced from the challenge server's system prompt (foray_challenge_server.py:107), the canonical guidance the decomposition engine applies to every AI-agent transaction submitted via /decompose:
> AGENT IDENTITY RULE: When an AI agent or human agent acts on behalf of a principal, the principal is always the party in the Arrangement. The agent is the instrument of execution, not the counterparty. Record the agent's role in the rationale. The Action records what the agent did, but the Arrangement parties are always the principals. If the agent exceeds its mandate, the divergence between the Arrangement scope and the Action is structurally visible.
AGENT-ID)
Two more entries carry AGENT-ID but in non-autonomous contexts:
| # | Name | Cluster | Status | Patterns |
|---|---|---|---|---|
| 319 | Virtual Power Plant | Energy | Clean | AGENT-ID, PARALLEL |
| 434 | Lloyd's Broker Placing | Insurance Broking | Clean | AGENT-ID, PARALLEL |
These show that the AGENT-ID pattern applies anywhere a principal-agent relationship exists — a software-driven Virtual Power Plant or a human Lloyd's broker. The pattern's invariant is structural, not technological.
GATE-ATT, CHAIN-ATT)
Loomworks' Memory has provenance built into every assertion (the provenance JSONB column). When provenance walks through multiple agents (e.g., Companion classifier → responder → committer), that is structurally a CHAIN-ATT. Selected entries:
| # | Name | Cluster | Status | Patterns |
|---|---|---|---|---|
| 27 | Carbon Credit Transaction | Environmental Services | Clean | TYPE6-CREATE, CHAIN-ATT |
| 40 | Clinical Trial Milestone | Biotech | Clean | COND-ACT, GATE-ATT |
| 42 | Organ Procurement Chain | Healthcare | Watch | TYPE7-DESTRUCT, CHAIN-ATT |
| 399 | Nuclear Fuel Fabrication | Nuclear | Clean | TYPE3-TRANSFORM, GATE-ATT |
| 459 | Fill and Finish Contract | Life Sciences | Clean | DYN-GOV-REF, GATE-ATT |
| 569 | Physical Commodity FOB | Commodities | Clean | CHAIN-ATT, TYPE1 |
| 601 | Forest Carbon REDD+ | Forestry | Clean | TYPE6-CREATE, CHAIN-ATT |
| 707 | CBDC Cross-Border Corridor | Cross-Border | Clean | PARALLEL, CHAIN-ATT |
| 853 | Vaccination Programme Government | Public Health | Clean | DIRECTING-AUTH, CHAIN-ATT |
| 890 | Self-Sovereign Identity Credential | Digital Identity | Clean | TYPE6-CREATE, CHAIN-ATT |
The CHAIN-ATT pattern (Manuka honey is the canonical example from the protocol deep-read — laboratory → certifier → regulator) is the pattern that most directly applies to a Loomworks-as-FORAY-attester architecture: each Companion turn could be an attestation chained from the prior turn.
APPEND-ONLY boundary entries (15 total — all "Flaw"-tagged)
All 15 Flaw entries share APPEND-ONLY. These are the canonical protocol boundaries:
| # | Name | Cluster | Patterns |
|---|---|---|---|
| 95 | Retroactive Price Adjustment / True-Up | Financial Instruments | APPEND-ONLY, SUNK-COST |
| 112 | Novation — Contract Party Replacement | Legal | APPEND-ONLY, PARENT-REF |
| 116 | Circular Guarantee | Legal | APPEND-ONLY, COMP-CONTINGENT |
| 160 | Carried Interest with Clawback | Private Equity | APPEND-ONLY, NON-MONO |
| 172 | Hospital Charity Care Write-Off | Healthcare | APPEND-ONLY, SUNK-COST |
| 222 | Anti-Dumping Duty Retroactive Assessment | Trade | APPEND-ONLY, DIRECTING-AUTH |
| 427 | Viral Content Retroactive Licence | Social Media | APPEND-ONLY, PARENT-REF |
| 433 | Novation of Design Consultant | Architecture | APPEND-ONLY, PARENT-REF |
| 454 | CCP Clearing — Novation at Scale | Clearing | APPEND-ONLY, MULTI-PARTY |
| 538 | Collective Action Clause Restructuring | Sovereign Debt | APPEND-ONLY, DIRECTING-AUTH |
| 622 | Transfer Pricing Oracle Dispute | Oracle Dispute | APPEND-ONLY, ORACLE-DISP |
| 671 | PPP Renegotiation — Mid-Contract | PPP | APPEND-ONLY, DIRECTING-AUTH |
| 757 | API Terms of Service Unilateral Change | Tech Licensing | APPEND-ONLY, PARENT-REF |
| 797 | Fast Fashion Order Cancellation Mid-Production | Textile | APPEND-ONLY, SUNK-COST |
| 875 | Voluntary Carbon Standard Revision | Carbon Markets | APPEND-ONLY, TYPE6-CREATE |
These cases are directly analogous to Loomworks' R-A28 Memory non-erasure rule. When an engagement-memory event needs to be "corrected," the substrate creates a new event referencing the original — never modifies it. The PARENT-REF pattern is the mechanism.
Worth noting because they push the claim's universality:
| # | Name | Cluster | Status | Patterns |
|---|---|---|---|---|
| 202 | Mesopotamian Grain Loan 2000 BCE | Historical | Clean | SCALE-INV, FORMULA |
| 207 | Dutch Tulip Bulb Forward 1637 | Historical | Clean | SCALE-INV, FIXED |
| 919 | Hammurabi Grain Loan 1750 BCE | Universal | Clean | SCALE-INV, FORMULA |
| 920 | Roman Collegium Burial Insurance | Universal | Clean | SCALE-INV, MIN-CONFIG |
| 922 | East India Company Share | Universal | Clean | SCALE-INV, TYPE8 |
| 923 | Future Transaction 2075 Orbital Habitat | Universal | Clean | SCALE-INV, FIXED |
| 924 | Negative Price Commodity | Grammar Boundary | Clean | REVERSE-DIR, VALUATION-BASED |
| 927 | Transaction with No Asset Pure Commitment | Grammar Boundary | Clean | MIN-CONFIG, ANTICIPATION-ONLY |
| 928 | Self-Referencing Party on Both Sides | Grammar Boundary | Clean | TYPE3-TRANSFORM, SELF-REF |
| 1001 | The FORAY Protocol Itself | Meta | Clean | TYPE6-CREATE, PARENT-REF |
Entry 1001 is the protocol decomposing its own existence. The library carries the meta-claim that FORAY-the-thing is itself a FORAY-decomposable transaction (a Type 6 Creation with a parent reference). This is a small piece of evidence that the grammar's claim to universality includes itself.
The kickoff frames this precisely: "the calling system sends FORAY-specific information about its native transactions to FORAY." What does that mean concretely?
The challenge site demonstrates the construction half of the integration, not the submission half. The user types natural-language English. The /decompose endpoint hands the text to Claude with a 100-line system prompt (FORAY_SYSTEM_PROMPT in foray_challenge_server.py:29-220) that returns a fully-structured 4A decomposition as JSON.
The structure returned (per server.py:135-220) is the FORAY-specific information. Reproduced verbatim from the server's expected response shape:
{
"transaction_type": "Brief name for this transaction type",
"summary": "One sentence description",
"components_present": ["arrangement", "accruals", "anticipations", "actions"],
"arrangement": {
"transaction_type": "controlled vocabulary type",
"parties": ["Party A description", "Party B description"],
"rationale": "Why this Arrangement is or is not present"
},
"accruals": {
"items": [
{
"accrual_id": "AC-001",
"type": "fixed | formula-based | valuation-based",
"obligor": "who owes",
"beneficiary": "who receives",
"amount": 0.00, // fixed
"formula": "...", // formula-based
"inputs": { ... }, // formula-based
"oracle": "...", // valuation-based
"observation_point": "...",
"governing_reference": "...",
"description": "...",
"spawns_arrangement": false
}
],
"rationale": "..."
},
"anticipations": {
"items": [
{
"anticipation_id": "AN-001",
"type": "projection | awareness | contingent",
"from_party": "...",
"to_party": "...",
"asset_type": "asset class only — USD, equity, commodity, right, data",
"quantity": 0.00,
"accrual_ref": "AC-001 if quantity derives from an Accrual",
"expected_date": "ISO 8601 or descriptive timing",
"description": "..."
}
],
"rationale": "..."
},
"actions": {
"items": [
{
"type": "transfer | state-change",
"from_party": "...",
"to_party": "...",
"asset_type": "...",
"quantity": 0.00,
"accrual_ref": "AC-001 if quantity derives from an Accrual",
"anticipation_ref": "AN-001 if this Action resolves an Anticipation",
"timestamp": "ISO 8601 or 'at execution'",
"description": "..."
}
],
"rationale": "..."
},
"fits_grammar": true | false,
"fit_assessment": "Assessment text",
"structural_insight": "2-3 sentences explaining the key structural decision in this decomposition",
"challenge_worthy": true | false,
"challenge_note": "If this transaction reveals a potential limitation, describe it"
}
The challenge site's answer to "who builds the FORAY-specific structure" is an AI agent (Claude Sonnet 4) acting on behalf of the calling system, instructed by a long, precise system prompt (the FORAY_SYSTEM_PROMPT in server.py).
The system prompt itself is the most valuable artifact for understanding the construction pattern. It is roughly 100 lines of decomposition discipline including (verbatim section labels): NATURAL LANGUAGE RULE, REFERENCE ASSETS, CONTINGENT NON-OCCURRENCE, DESTRUCTION WITH NO RECIPIENT, UNKNOWN PARTIES, MULTIPLE RESOLUTION PATHS, NON-MONOTONIC ACCRUALS, CHILD TRANSACTIONS, CONTINUOUS RESET ACCRUALS, DISCRETIONARY ACCRUALS, PARTIAL REVERSAL, NOVATION, SAME-ARRANGEMENT MULTIPLE ACTIONS, CONDITIONAL ACCRUAL ACTIVATION, PARALLEL INDEPENDENT ACCRUALS, ACCRUAL PARTY SCOPE, PERIODIC CRYSTALLISATION, EXECUTION-TIME ORACLE, BAND STRUCTURE ACCRUALS, PROPORTIONAL MULTI-PARTY ACCRUALS, MULTI-TIER CONDITIONAL ACTIVATION (WATERFALL), CONDITIONAL DEACTIVATION (SUSPENSION), AGENT IDENTITY RULE, FORCE MAJEURE RETIREMENT, DESIGNED CONTINGENCY MASS RETIREMENT, REVERSE DIRECTION ACCRUALS, ARRANGEMENT CONDITIONS VS COMPONENTS, REGULATORY DEFERRAL, DESIGNED PERIODIC DEFERRAL, COMPETING CONTINGENT RESOLUTION, APPEND-ONLY IN RESTRUCTURING, ASSET TYPE VS QUANTITY SEPARATION, COMPONENT PRESENCE, ACCRUAL INPUTS.
Each section is one paragraph of guidance. Reading the full prompt is reading the de facto FORAY style guide for decomposition. The challenge tool is the SDK in operation — Claude+prompt = "the FORAY decomposition engine."
Per the challenge tool's flow:
The boundary is the LLM call. The site demonstrates a posture: the calling system does not need to know FORAY's internal grammar in advance. It sends a description; the decomposition engine (instructed via the system prompt) produces the 4A structure. A more rigorous integration would have the calling system construct the 4A structure directly (the way the quickbooks-adapter.js does — see protocol deep-read §5), but the challenge tool shows a fallback path: even a system that knows nothing about FORAY can produce valid 4A through an LLM-mediated adapter.
The challenge tool builds just-in-time, per transaction. Each /decompose call is one transaction → one 4A structure. The /library/submit endpoint then captures the decomposition into an append-only JSON log (library_submissions.json) for later curation. The site does not batch.
The decomposition prompt requires:
Everything else — parties, dates, amounts, formulas — is extracted from the description by the LLM. If a required field is genuinely unknown ("Open Recipient", "Unknown Counterparty"), the prompt instructs the engine to use a placeholder rather than hallucinate (per the UNKNOWN PARTIES section).
This is the loose-coupling pattern: the source system can be as minimal as a plain-English event log, and the FORAY adapter does the structural work. The protocol deep-read showed the opposite end of the spectrum (quickbooks-adapter.js building components directly from typed source data). The challenge site demonstrates the LLM-mediated alternative.
The challenge site does not document a FORAY anchor-service wire interface. It documents two things instead:
From foray_challenge_server.py:
| Method | Path | Purpose |
|---|---|---|
| GET | / | Serve challenge index HTML |
| GET | /library | Serve library index HTML |
| GET | /about | Serve about HTML |
| POST | /sample | Generate a sample transaction description from a seed (LLM-backed) |
| POST | /decompose | Decompose a transaction description into 4A JSON (LLM-backed) |
| POST | /library/submit | Append a decomposition to the community submissions log |
| POST | /generate | Generate a decomposition for a named library entry (LLM-backed) |
| POST | /bulk-test-start | Internal bulk-validation entry point (visible at server.py:519) |
| GET | /health | Liveness check |
The /decompose and /generate endpoints use Claude Sonnet 4 (claude-sonnet-4-20250514, server.py:309 and 497). The system prompt is the FORAY_SYSTEM_PROMPT covered in §4 above.
The kickoff asked for:
None of these are documented on the challenge site. The site assumes the protocol is the standard and any compliant implementation suffices — the submission envelope is the contract, the persistence layer is declared by the submitter, and "the FORAY anchor service" as a singular HTTP API does not exist as such.
The closest thing to an SDK is the absent foray-sdk.js referenced by quickbooks-adapter.js (covered in the protocol deep-read §5). Calls to this.sdk.anchorToBlockchain(transaction) exist in adapter code but the SDK implementation is not in any of the repos I have access to (foray-kaspathon or foray-protocol-db).
Honest reading: the challenge site reinforces the protocol-level position that FORAY is a standard, not a service. Anchoring happens against whatever persistence layer the submitter declares; the wire interface to that persistence layer (Kaspa, in the reference implementation) is a Kaspa concern, not a FORAY concern.
Across the library, the entry that most closely resembles Loomworks structurally is:
Entry #472 — "Emergent Agent Transaction"
AGENT-ID, SCALE-INV[472,"Emergent Agent Transaction","Autonomous","Clean",["AGENT-ID","SCALE-INV"]]The kickoff asks specifically for "the use case Loomworks should pattern its FORAY integration after." This is it.
Why this is the match:
AGENT-ID pattern + the AGENT IDENTITY RULE in the server prompt) makes the Operator the Arrangement party and the Companion the instrument — exactly the Loomworks architecture.The full Autonomous cluster plus the two agent-mediated entries form the structural family:
| # | Name | Patterns | Why it parallels Loomworks |
|---|---|---|---|
| 232 | AI Agent Autonomous Procurement | AGENT-ID, EXEC-ORACLE | Agent decides at execution time (the Companion classifies and responds at runtime, not at design time) |
| 464 | Autonomous Procurement Below Threshold | AGENT-ID, EXEC-ORACLE | Agent acts within delegated authority (the Companion has bounded mandate) |
| 470 | Smart Contract Code-Triggered Payment | AGENT-ID, MIN-CONFIG | Action without ceremonial Arrangement (a Companion turn produces effect without first issuing a contract) |
| 472 | Emergent Agent Transaction | AGENT-ID, SCALE-INV | The exact pattern match |
| 319 | Virtual Power Plant | AGENT-ID, PARALLEL | Aggregator agent coordinating parallel principal actions |
| 434 | Lloyd's Broker Placing | AGENT-ID, PARALLEL | Human-agent variant of the same principal-instrument pattern |
If Loomworks adds FORAY as an additive audit layer (the Operator's framing), the integration would treat each significant engagement event as one transaction structured like this:
ARRANGEMENT:
transaction_type: "engagement_companion_session" (or similar)
parties:
- {role: "operator", name_hash: <Operator's hashed identity>}
- (optional) other engagement members
(the Companion is the instrument, not a party)
ACCRUAL(S):
- Token consumption (classifier + responder LLM calls)
type: formula-based
obligor: Operator
beneficiary: Anthropic (via dunin7)
formula: token_count × rate_per_million
- Credit debit (already implemented in Loomworks' credit substrate as
credit.foray_action_flows, per the substrate inventory)
ANTICIPATION(S):
- Optional. For deferred work (drafts in progress, approval cards),
an Anticipation records that some action is projected.
ACTION(S):
- The actual write to Memory (assertion_committed, etc.)
type: state-change (if Memory write only) or transfer (if value moved)
timestamp: when committed
description: "Companion-mediated assertion commit"
ATTESTATION(S):
- The Companion attests what it did (classifier output, routing decision)
- The Operator attests their approval (WebAuthn signature at commit)
- Chain: Operator-WebAuthn → Companion-classifier → Companion-responder → Action
This is the CHAIN-ATT pattern wrapped around an AGENT-ID core. The protocol deep-read found that the Schema Reference (§3.1) names "AI agent observability connects to business transaction accountability" as a canonical attestation use case — this is what that means structurally.
No exact "knowledge management" or "AI assistant mediating between users and a substrate" use case appears in the library. The Autonomous cluster is the closest structural parallel — but it is procurement / payment / coordination examples, not knowledge work. The match is at the level of pattern (AGENT-ID + SCALE-INV), not at the level of named transaction type.
If the Operator wants a closer use-case match, they could submit a "Knowledge Substrate Companion Session" entry to the library — this would be exactly the kind of community submission the about page invites ("0 community submissions" today). A Loomworks-shaped library entry doesn't exist because no one has submitted it.
The challenge site addresses this through two artifacts:
foray_challenge_index.html hero):> "Every business transaction fits four components. Prove us wrong." > > "Describe any business transaction. The FORAY Protocol will decompose it into Arrangements, Accruals, Anticipations, and Actions. If the grammar fails, we want to know." > > "No transaction in any industry, jurisdiction, or era has required a fifth component." > > "The protocol has 10 documented boundaries — transactions that resolve via parent reference rather than inside a single record."
This is the maximalist framing: FORAY claims to decompose every business transaction, period. It does not say "FORAY is appropriate for some transactions and not others." The site's stance is universality.
The about page reinforces this:
> "DUNIN7 publishes the protocol. DUNIN7 does not operate it." > > "FORAY is a protocol — a universal grammar, not a service. Like TCP/IP, it defines the standard. Implementations evolve. Persistence layers change. Connectors multiply. The protocol survives all of it."
The implication is that FORAY does not opt in to use cases — it always applies if you choose to apply it. What is optional is whether you integrate FORAY at all, not which of your transactions it can describe.
The site does not list criteria for "when to integrate FORAY vs not." The kickoff anticipated such criteria would exist; the site has no such material. The RFC-0001 closing (line 122) frames the optionality differently:
> "Connector implementations. Build a FORAY-compliant connector for any source system. The connector specification defines the submission schema. Any system that can produce a valid FORAY submission is a compliant source. There is no certification required to build. Certification is available for those who want it."
The framing is: the decision to integrate FORAY is the connector author's decision. Once integrated, every transaction the connector emits is a FORAY transaction. The granular "which of my transactions should I anchor" question is treated as out-of-scope at the protocol level.
The substrate review's question "which Loomworks events should be FORAY-anchored?" is a Loomworks-side decision, not a FORAY-side decision. The challenge material does not provide criteria; it provides a universal grammar that holds for whatever the calling system chooses to anchor.
Concretely: if Loomworks decides to FORAY-anchor every assertion_committed event, the grammar will fit. If Loomworks decides to FORAY-anchor only Operator-WebAuthn-confirmed commits, the grammar will fit. If Loomworks decides to FORAY-anchor only billable Companion turns, the grammar will fit. The choice is operational, not protocol-mandated.
The Operator's framing ("FORAY is additive, not mandatory") is consistent with what the site says: FORAY is a tool, not a requirement. The site itself names no "don't bother anchoring this" cases.
It's worth flagging that the 15 Flaw entries (§3 Group D) are sometimes mistaken for "use cases where FORAY doesn't work." They are not. The site's own status tooltip is explicit (verbatim):
> Flaw — "A protocol boundary constraint — not a grammar failure. The append-only architecture means this transaction requires a new submission with a parent reference rather than a modification. Master-level territory."
Flaw entries fit the grammar; they just resolve via parent reference (a new submission with a parent_reference field set) rather than via modification of the original. This is exactly Loomworks' R-A28 mechanism. No transaction is excluded.
The challenge site does not show persistence-layer choices per use case. This is consistent with the protocol deep-read's finding that persistence is declared by the submitter and is layer-agnostic.
What the site does demonstrate:
library_submissions.json file (an append-only JSON log on the Mac Mini, not Kaspa).persistence[] field per submission (covered in protocol deep-read §5) but the challenge tool does not exercise it.
Honest reading: the challenge site is a protocol-validation tool, not a persistence-layer demonstration. The persistence layer (Kaspa or otherwise) is referenced as a property of "real" submissions but the demo does not perform anchoring. The README explicitly notes (README.md):
> "FORAY anchors cryptographic fingerprints of your transactions and agent actions to Kaspa's blockchain in real-time. The data stays in your systems. Only the proof goes on-chain."
This is the conceptual position; concrete persistence-layer wiring is in the foray-kaspathon adapter code, not on this site.
The Autonomous cluster (covered in §3 Group A and §6) is the canonical AI-agent material. There is no explicit "Companion mediating between users and a substrate" use case — but the AGENT-ID pattern + the AGENT IDENTITY RULE in the server prompt give the structural answer.
Per the AGENT IDENTITY RULE (server.py:107, reproduced exactly):
> When an AI agent or human agent acts on behalf of a principal, the principal is always the party in the Arrangement. The agent is the instrument of execution, not the counterparty. Record the agent's role in the rationale. The Action records what the agent did, but the Arrangement parties are always the principals. If the agent exceeds its mandate, the divergence between the Arrangement scope and the Action is structurally visible.
For Loomworks specifically:
This is consistent with the protocol deep-read's finding (Schema Reference §3.1): "This is the layer where AI agent observability connects to business transaction accountability. An AI agent's decision cycle — authorisation check, reasoning, projection, execution — is a sequence of events, not a business transaction. Each event is a claim made by the agent about what it did and why."
The challenge site shows agent identity as a hashed identifier in the Arrangement (the principal) plus role-in-rationale (the agent). The agent itself does not appear as a party. Concretely, from a fleshed-out Library entry's decomposition pattern:
The challenge site does not show concrete agent-identity attestation JSON because it does not show concrete attestations at all (the demo's /decompose endpoint doesn't produce attestations field — only the four core components plus assessment metadata). The Manuka honey example in the protocol deep-read is the closest concrete attestation chain.
If the Operator clicks "AI Agent Autonomous Procurement" (#232) in the library UI, the /generate endpoint produces a fresh decomposition on demand. This is not stored anywhere — it is regenerated each click. I can describe the expected shape from the system prompt, but cannot reproduce a specific concrete decomposition without invoking the server.
Mark of uncertainty: the exact wording the LLM produces for #232 would be a useful artifact for Loomworks' substrate review. The Operator could invoke it directly via the live site (clicking the row in the library) and capture the output for future reference.
The kickoff's Topic 1 asks for 4-8 use cases reproduced at the integration-detail level. The challenge site does not present that material. Marking this honestly: what the kickoff requests cannot be produced from this source. The reason is structural — the site is a protocol validator, not an integration showcase.
The closest substitute, paraphrased here, is the cross-product of (cluster → most-illustrative entries → pattern shape). The substantive integration-pattern picture the kickoff was seeking is:
quickbooks-adapter.js) reads invoices via the ERP API, builds 4A components from typed fields, calls sdk.anchorToBlockchain(transaction). Library entries that pattern this: most of the Merchant Banking, Manufacturing, Healthcare, Real Estate clusters.salesforce-adapter.js extracts opportunity records, maps to 4A components, anchors. Library entry: #232 (AI Agent Autonomous Procurement) shares structural shape with most CRM-driven transactions.PARALLEL Accruals (drug/labour/overhead) + DIRECTING-AUTH (regulator or insurer) + sometimes CHAIN-ATT (lab → clinician → insurer).
The FORAY_SYSTEM_PROMPT in foray_challenge_server.py:29-220 is the most operationally substantive artifact on the site. It is the de facto style guide for FORAY decomposition — 33 named sections of decomposition discipline, each one paragraph. For Loomworks-as-FORAY-system, this prompt is closer to "the spec we need to follow when constructing FORAY transactions" than the schema reference is. The schema defines field shapes; the prompt defines field semantics under ambiguous real-world conditions.
A Loomworks-side FORAY adapter that wanted to produce 4A structures from engagement events would benefit from constructing its prompt around this same 33-section discipline — or at minimum the subset relevant to AI-agent transactions (AGENT IDENTITY RULE, NATURAL LANGUAGE RULE, ASSET TYPE VS QUANTITY SEPARATION, APPEND-ONLY IN RESTRUCTURING, COMPONENT PRESENCE).
From foray_about.html line 94:
> "The library currently contains 1,000+ in-house validation entries and 0 community submissions."
The protocol claim has been tested only in-house. The library is a single-author taxonomy. This is honestly disclosed. For Loomworks substrate review, it means: when the substrate review treats the FORAY material as canonical, it should treat the underlying validation as "extensive but unilateral" — not as community-stress-tested.
This is operationally important. The substrate review doesn't need to revise its trust posture, but it should know that the 1,001 transaction types reflect Marvin's mapping discipline, not community consensus.
The server's /library/submit endpoint (server.py:339) is fired automatically on every successful /decompose call (client-side in foray_challenge_index.html line 400, submitToLibrary(tx,data)). Source-tagged with chip:X, build_example:X, surprise_me:X, or user_described. The captured submissions are not surfaced anywhere visible on the site — they accumulate in ~/static/library_submissions.json on the Mac Mini for later review and credit assignment.
For Loomworks substrate review: this is the pattern the substrate review's "AI agent observability" framing should follow — every decomposition the system generates is preserved with source tagging, no matter the outcome. The substrate doesn't need to decide upfront which decompositions matter; it preserves everything and curates later.
The library has 80+ industry clusters but the pattern-code system (22 patterns) is the more useful taxonomy for cross-cluster comparison. A "Commercial Mortgage" (Real Estate) and a "Whisky Cask Maturation" (Dynamic Value) both carry DYN-GOV-REF — the cluster is different, the structure is the same. For substrate-level reasoning about FORAY, the pattern codes are the right index.
The library stat bar (line 226) reads "10 — Boundaries". The Flaw-tagged entries number 15, but they share boundaries — multiple entries can hit the same boundary. The 10 boundaries are not enumerated as a list on the site (the library has a button "See the boundary catalogue →" but it appears to link back to the library itself, suggesting the boundaries are implicit in the Flaw-tagged rows rather than a separate catalogue).
The kickoff Topic 6 (boundary edge cases) for the protocol deep-read was answered via Schema Reference §10.3 / §11. The challenge site reinforces the count (10) but does not enumerate them as a standalone list.
| Topic | What's missing | Why |
|---|---|---|
| Use cases per system type (Topic 1) | Integration patterns by source-system type (ERP, CRM, healthcare, agentic system) with calling shape and data flow | Site is a protocol validator, not an integration showcase. Integration-pattern material lives in the foray-kaspathon adapters and the protocol deep-read covered it. |
| Wire-level FORAY service interface (Topic 3) | Endpoints, request/response shapes, auth, error handling | Site does not expose this material. The foray-sdk.js referenced by adapters is absent from both this repo and the foray-kaspathon repo. |
| Persistence layer choices in practice (Topic 4) | Per-use-case persistence selection, multi-layer examples | Site does not demonstrate anchoring at all. The persistence layer is conceptually described but no use case shows the choice. |
| Concrete attestation chains (Topic 5) | Worked attestation JSON for AI-agent transactions | Library entries are descriptions + status + patterns, not full JSON. To get concrete JSON, the Operator would click a row and the LLM produces fresh output. |
| Loomworks-shaped use case (Topic 6) | An exact named knowledge-substrate / Companion / multi-tenant-knowledge-management entry | Not in library. The Autonomous cluster (especially #472 Emergent Agent Transaction) is the closest structural family but is procurement/payment-flavoured, not knowledge-work-flavoured. |
| When-to-FORAY criteria (Topic 7) | A list of "anchor this, not that" criteria | The site's stance is that FORAY's grammar applies universally; the decision to integrate is the calling system's decision. There is no per-event "should we anchor" guidance. |
For Loomworks substrate review, the three deep-reads compose:
/Users/dunin7/Downloads/foray-protocol-deep-read-v0_1.md) — protocol-level: ATT-* rules, audit_data, worked transaction, trust model, anchor service, boundary edge cases, framing drift./Users/dunin7/loomworks-record/substrate/loomworks-substrate-inventory-v0_1.md) — the actual current state of Loomworks' substrate, against which any FORAY integration would be designed.
These three together give the substrate review the grounded picture the Operator has been asking for. The Loomworks-shaped use case — Library entry #472 "Emergent Agent Transaction," in the Autonomous cluster, tagged AGENT-ID + SCALE-INV — is the recommended pattern anchor.
End of challenge-site deep-read.