FORAY Challenge Site Deep-Read — v0.1

The three pages at foraychallenge.dunin7.com

To answer the kickoff's "what kind of system is integrating, what data does it construct, what does it send to FORAY" — that material lives in the adapter code (covered in the protocol deep-read), not on this site. The gap is real and treated honestly throughout the rest of this document.

1. The 22 named decomposition patterns — the integration-pattern surrogate

Because the site does not present integration 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. Each one names a recurring decomposition shape that appears across multiple library entries. Any calling system integrating FORAY must classify its native transactions into one or more of these patterns. The pattern determines how source-system events map into 4A components.

The Clean / Watch / Flaw status taxonomy

Every library entry carries one of three statuses. The site's tooltip definitions, verbatim:

• Clean — "The grammar handles this transaction correctly under current rules. A model decomposition with no guidance needed. Associate-level pattern."
• Watch — "The grammar handles this but the engine needs guidance. Parallel Accruals, conditional activation, or non-monotonic structures require careful decomposition. Practitioner-level pattern."
• 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."

2. Library entries that matter for Loomworks

The library is 1,001 transactions long. Rendering them all would be noise. The entries that matter for a Loomworks-as-FORAY-system understanding fall into four groups.

Group A — The Autonomous cluster

These four entries explicitly model AI/algorithmic agents producing transactions on behalf of principals. This is the closest cluster to Loomworks' structural shape.

The AGENT-ID pattern is the load-bearing one. The decomposition discipline:

• The principal is the Arrangement party.
• The agent is the instrument of execution.
• The Action records what the agent did, but the parties to the Arrangement are the principals.
• If the agent exceeds its mandate, the divergence between the Arrangement scope and the Action is structurally visible.

From the challenge server's system prompt (foray_challenge_server.py:107) — the canonical guidance the decomposition engine applies to every AI-agent transaction:

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.

Group B — Agent-mediated transactions outside Autonomous

Two more entries carry AGENT-ID in non-autonomous contexts:

The pattern applies anywhere a principal-agent relationship exists — software-driven Virtual Power Plant or human Lloyd's broker alike. The pattern's invariant is structural, not technological.

Group C — Attestation patterns

Loomworks' Memory has provenance built into every assertion (the provenance JSONB column). When provenance walks through multiple agents (Companion classifier → responder → committer), that is structurally CHAIN-ATT.

The canonical CHAIN-ATT example is the Manuka honey chain (laboratory → certifier → regulator) from the protocol deep-read. The pattern applies directly to a Loomworks-as-FORAY-attester architecture: each Companion turn could be an attestation chained from the prior turn.

Group D — APPEND-ONLY boundary entries (the 15 "Flaw"-tagged)

All 15 Flaw entries share APPEND-ONLY. These are the canonical protocol boundaries.

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.

Group E — Historical and meta entries

Worth noting because they push the claim's universality:

Entry 1001 is the protocol decomposing its own existence — a Type 6 Creation with a parent reference. The library carries the meta-claim that FORAY-the-thing is itself a FORAY-decomposable transaction. A small piece of evidence that the grammar's claim to universality includes itself.

3. The Loomworks-shaped use case

[472,"Emergent Agent Transaction","Autonomous","Clean",["AGENT-ID","SCALE-INV"]]

Why this is the match:

• Loomworks is an emergent-agent system — the Companion produces outcomes (assertions, knowledge artifacts, drafts) on the Operator's behalf, not via predefined contract clauses but through emergent decision-making at runtime.
• Loomworks is scale-invariant — the grammar holds whether a single Operator runs one engagement or many Operators run thousands; the structural shape doesn't change.
• The decomposition discipline (per the AGENT-ID pattern + the AGENT IDENTITY RULE) makes the Operator the Arrangement party and the Companion the instrument — exactly the Loomworks architecture.

The four supporting matches

The full Autonomous cluster plus the two agent-mediated entries form the structural family:

What this means for Loomworks-as-FORAY-system

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.

Honest qualification

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 its entries are procurement, payment, and 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 — 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 yet.

4. The FORAY_SYSTEM_PROMPT — the de facto style guide

The most operationally substantive artifact on the site is not a use case or a UI feature. It is the FORAY_SYSTEM_PROMPT in foray_challenge_server.py:29-220 — roughly 100 lines of decomposition discipline. This prompt is the de facto FORAY style guide. The schema defines field shapes; the prompt defines field semantics under ambiguous real-world conditions.

The prompt has 33 named sections, each one paragraph of guidance. Reading the full prompt is reading the de facto style guide for FORAY decomposition. The challenge tool is the SDK in operation — Claude + prompt = "the FORAY decomposition engine."

The 33 named sections

Section labels reproduced verbatim from the prompt:

• 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 (the Loomworks-relevant one)
• 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

5. The FORAY-specific information pattern — what gets sent

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 the FORAY_SYSTEM_PROMPT and 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"
}

Who builds 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 the long system prompt described above.

Where the boundary sits

• Source-system-native side: natural language English describing what happened. For example: "Marvin invoiced ACME Corp $10,000 for consulting services. ACME paid net 30 by ACH transfer on March 15."
• FORAY-side: the structured JSON above — typed components, typed references, controlled-vocabulary fields.

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 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 — protocol deep-read §5), but the challenge tool shows a fallback path.

Required vs optional source information

The decomposition prompt requires at least the textual description. That's it. Everything else — parties, dates, amounts, formulas — is extracted from the description by the LLM. If a field is genuinely unknown ("Open Recipient", "Unknown Counterparty"), the prompt instructs the engine to use a placeholder rather than hallucinate.

6. The FORAY service interface — what the site does and doesn't show

The challenge site does not document a FORAY anchor-service wire interface. It documents two things:

1. The challenge server's own API — three endpoints for the challenge/library UX. These are not the FORAY protocol's service interface; they are the demo app's interface.
2. The submission envelope shape (in SCHEMA.md) — the canonical FORAY submission contract. Already covered in the protocol deep-read §5.

The challenge server's endpoints (for reference, not for integration)

The /decompose and /generate endpoints use Claude Sonnet 4 (claude-sonnet-4-20250514).

What is genuinely undocumented on the site

The kickoff asked for the wire-level interface for anchoring, the SDK shape, sync vs async semantics, and error handling. 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 reviewed repo.

7. When FORAY adds value, when it doesn't

The challenge site's framing on this question is unambiguous:

"Every business transaction fits four components. Prove us wrong."

"No transaction in any industry, jurisdiction, or era has required a fifth component."

"FORAY is a protocol — a universal grammar, not a service. Like TCP/IP, it defines the standard."

This is the maximalist framing: FORAY claims to decompose every business transaction, period. The site does not say "FORAY is appropriate for some transactions and not others." The stance is universality.

What the site does NOT say

The site does not list criteria for "when to integrate FORAY vs not." The kickoff anticipated such criteria would exist; they don't. RFC-0001 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."

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 Flaw-tagged entries are protocol boundaries, not "don't use FORAY" advice

The 15 Flaw entries are sometimes mistaken for "use cases where FORAY doesn't work." They are not. The site's own status tooltip is explicit: "A protocol boundary constraint — not a grammar failure." Flaw entries fit the grammar; they just resolve via parent reference rather than modification. This is exactly Loomworks' R-A28 mechanism. No transaction is excluded.

8. Other substantive findings

The community is empty

From the about page:

"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. 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 /library/submit endpoint auto-captures every decomposition

The server's /library/submit endpoint fires automatically on every successful /decompose call. 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 pattern-code system is more discoverable than the cluster system

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.

There are exactly 10 documented protocol boundaries

The library stat bar 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 boundaries are implicit in the Flaw-tagged rows. 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.

9. Things asked for but not found

Closing — what to read this alongside

For Loomworks substrate review, the three deep-reads compose:

1. The protocol deep-read — protocol-level: ATT-* rules, audit_data, worked transaction (Manuka), trust model, anchor service, boundary edge cases, framing drift.
2. This document — integration-pattern-level: the library taxonomy, the 22 pattern codes, the Autonomous cluster as the Loomworks parallel, what the challenge site does and doesn't say.
3. The substrate inventory — 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.