Version. 0.1 Date. 2026-05-08 Status. Investigation. Integration sequencing across multiple build arcs, with OVA-stub-progression pattern as an architectural commitment worth preserving. Closes the session's coherent four-piece arc by extending the OVA load-following observation into a concrete integration plan. Author. Claude.ai (investigation layer). Operator: Marvin Percival. Provenance. Conversation initiated by the Operator's three-part question: when is it appropriate to implement FORAY and OVA so Loomworks integration can be tested; what alternatives for OVA would be sufficient as a surface for integration testing given that Kaspa vProgs aren't ready for full OVA implementation; and whether separate projects should be implemented to build out the integration surfaces. The conversation surfaced an asymmetry between FORAY (live, integratable now) and OVA (substrate not yet ready) that requires distinct treatment, and developed a stub-progression pattern that lets Loomworks's needs drive the OVA contract clarity. Informed by. All four prior investigations from this session: closed-loop engagement, knowledge elevation pathway, AIF playbook comparison, memory space extensibility. The protocol triangle (Loom remembers, OVA authorizes, FORAY audits) from methodology v0.18/v0.20. The OVA-as-load-following observation from the memory-space-extensibility investigation §3.4. Phase 45 CR (delegation contract, approval cards, OVA seam). FORAY status from user memory (live, BSL-1.1, Kaspathon 2026 Top 10, recommended anchoring substrate). OVA status from user memory (provisional patent March 2026, candidate access-control substrate, Kaspa vProg dependency for full implementation). Deployment Strategy v0.1/v0.2 (multi-instance fleet, jurisdiction governance via the protocol triangle).
The Operator opened with three coupled questions:
The questions are coupled but not symmetric. FORAY's substrate exists; OVA's substrate (Kaspa vProgs) does not. The integration timing for the two cannot be the same. The "separate projects" question further decomposes into several sub-questions about where stub code, integration code, specification work, and eventual implementation should live. Each sub-question has its own answer.
What lands: FORAY and OVA need different integration treatments because they have different substrate-readiness; a stub-progression pattern lets Loomworks's authorization needs drive OVA contract clarity ahead of vProg readiness; project boundaries should follow consumer count, not architectural neatness.
FORAY is live. The Kaspa anchoring works today. The question is not whether Loomworks can integrate but where in the build the integration earns its complexity tax.
Two competing considerations sit on either side of the timing decision:
Earlier integration is structurally cleaner. Wiring FORAY anchoring in before multi-Contributor work lands means every assertion commit, every promotion event, every cross-space operation is born with FORAY anchoring. Retrofitting auditability later means the audit trail starts at the wire-in date — historical events have no transaction records by definition. For some Operators that's acceptable; for regulated-domain Operators it's a gap in the audit story.
Later integration is cheaper. Wiring FORAY in now means every commit, promotion, retract, and redirect carries an extra round-trip. In single-Operator development that overhead has no visible benefit — the audit trail isn't being read by anyone. The complexity tax falls on every test run, every developer setup, every CI pipeline, every local dev cycle. Cumulatively significant.
The threading principle. FORAY integration belongs at the boundary where audit becomes load-bearing, not at the boundary where it becomes possible. Audit becomes load-bearing when two humans can disagree about what was committed, when, and by whom — that is, at multi-Contributor work. In single-Operator Loomworks the database is the audit trail and the Operator's own memory is the corroboration; that breaks under multi-Contributor load.
So FORAY integration follows multi-Contributor work into the build. The seam — what Loomworks calls when an audit-anchoring event occurs — is worth specifying earlier, because the seam definition is cheap and makes the eventual wire-in mechanical rather than design-fresh.
OVA proper depends on Kaspa vProgs, which are not yet ready. This creates a temporal mismatch: Loomworks's authorization needs grow with each architectural extension (per the load-following observation from the memory-space-extensibility investigation §3.4), while OVA's deployment is gated on vProg maturity that Loomworks does not control.
Phase 45 already commits to shipping an OVA seam without OVA behind it. That's the design pattern the user memory captured. The unresolved question is what fills the seam between Phase 45 ship and OVA-proper deployment.
The cleanest answer: Loomworks specifies the OVA contract as Loomworks needs to consume it, then runs an internal authorizer that satisfies the contract until OVA proper is ready. The internal authorizer is not OVA — it is a placeholder exposing the same interface OVA will eventually expose.
The seam-and-stub pattern fits because:
OVA integration is not waiting on vProgs. It is waiting on the contract being clear enough to specify. Contract clarity comes from doing integration work against a stub. So the integration begins now, against the stub, and OVA's contract hardens in parallel.
The conversation surfaced five candidate stub patterns, ordered by increasing fidelity to the eventual OVA shape. Each was evaluated against three criteria: how cleanly it matches OVA's expected semantic model, how cheap it is to implement and grow, and whether it teaches Loomworks code paths the right or wrong lessons about authorization.
The simplest stub. Each request carries a token; the authorizer validates the token and returns a scoped credential. No cryptographic agent identity, no delegation chains, no jurisdiction scoping.
Where it falls. Sufficient for testing that Loomworks code paths invoke the authorizer at the right boundaries; insufficient for testing the harder authorization questions (delegation chains, attenuation, cross-instance scoping). Useful as a starting point. Not useful as the long-term stub because it teaches Loomworks code paths to expect a credential model thinner than OVA will provide.
Tokens carry scoped capabilities — "this token authorizes commit on engagement X for assertion-class Y." Loomworks code requests capabilities; the authorizer issues them based on designation lookups; capabilities expire.
Where it lands. Matches OVA's actual semantic shape much more closely. Capability-based authorization is a well-understood pattern (object-capability security, macaroons, biscuit tokens) and a stub at this level can be implemented as a Python service in a few hundred lines. Gives Loomworks the right shape for integration testing — credential issuance, capability scoping, attenuation, expiration.
A specific instance of capability-based authorization with attenuation as a first-class operation. Macaroons let a holder of a credential mint a more-restricted credential without going back to the issuer — exactly the pattern needed for the Companion-delegates-to-task-agent-delegates-to-specialist credential chain raised in the closed-loop and memory-space-extensibility investigations.
Where it lands. Macaroons are mature (Google paper, 2014; production implementations in Hyperdex and several research systems). A Loomworks stub built on macaroons would probably be the highest-fidelity OVA placeholder available. Likely survives the eventual OVA swap because OVA's semantic model is plausibly close to macaroon-flavored anyway.
Why not start here. The commitment to a specific framework before the contract is clear can mislead Loomworks code paths into matching macaroon idioms that may not be exact OVA idioms. The seam-and-stub discipline argues for starting more abstract and migrating when the need crystallizes.
Run vProg-like logic on a substrate that's available now — Solana programs, Ethereum smart contracts, or a hosted policy engine like OPA (Open Policy Agent).
Where it falls. Trades cleanly against OVA's eventual semantics only if the chosen substrate's primitives map closely enough. If they don't — and most don't, because vProgs are specifically designed for the agent-authorization case — the stub teaches the wrong lessons. Loomworks code paths optimize for the stub's quirks; when OVA proper lands, those code paths need rewriting. Classic stub-becomes-permanent-fixture trap.
Probably not the right option unless Kaspa's vProg roadmap has a clear timeline making this an interim measure rather than a long-term substitute.
The most pragmatic option. Define the OVA API as Loomworks expects to consume it (authorize(actor, action, resource, context) → credential), implement it in Python or a small service, populate the authorization logic with whatever rules are appropriate for the present build state. As OVA's spec hardens, the API can be refined. As the build adds authorization needs, the stub grows.
Where it lands. Essentially Option B with less commitment to a specific capability model. Lets Loomworks's needs drive what the stub answers, rather than committing to macaroons or another specific framework before the contract is clear.
Start with Option E. The first version handles single-Operator delegation (Phase 45 scope) and is barely more than a function call. As multi-Contributor work, multi-space access, and agent-fabric credential chains come online, the stub grows.
Watch for the moment when ad-hoc authorization logic starts feeling like it wants a real capability model — that's the moment to consider migrating to macaroons (Option C) as the long-term stub. The migration trigger is internal pressure from the stub itself, not a calendar date.
The path is: seam first, stub behind it, semantic model emerges from need, swap to OVA when OVA's contract matches what the stub has been answering.
The third question — should separate projects be implemented to build out the surfaces — initially read as a single decision but turns out to decompose into several sub-questions, each with its own answer.
The Loomworks-side OVA stub belongs in Loomworks, not in a separate repo. Reasons:
The seam should be a clean abstraction (an Authorizer protocol that Loomworks calls; a default LocalAuthorizer implementation that satisfies the protocol). When OVA proper is ready, an OvaAuthorizer implementation replaces LocalAuthorizer. No project boundary needed.
FORAY itself is its own project (it exists). The Loomworks-side integration — the code that decides which Loomworks events anchor, what payloads they carry, how failures are handled — belongs in Loomworks, again because the integration's API surface is Loomworks-shaped. A separate Loomworks-FORAY-bridge project would be over-engineering at this scale.
Caveat. If there's eventual reuse — say, a future non-Loomworks project that also needs FORAY anchoring with similar event semantics — a small library of FORAY-anchoring helpers might earn its own home. Today, with one consumer (Loomworks), keep it inline.
OVA's specification — the contract that the eventual OVA implementation will satisfy — is a different artifact from either Loomworks or the stub. The spec wants its own home because:
When Kaspa vProgs are ready, OVA proper is built in its own project, depending on the OVA spec project for its contract. This is the standard pattern — implementation depends on specification, both have their own homes, both can evolve independently within the contract.
The framing question to test this: would another consumer of FORAY or OVA benefit from the integration code Loomworks is writing? If yes, separate. If no — and right now the answer is no — keep it inline.
Six concrete steps, sequenced for present-arc compatibility:
authorize(actor, action, resource, context) → credential, plus whatever supplementary calls Loomworks finds it needs. Output: an Authorizer protocol in Loomworks code. Time cost: hours, not days. Lands cleanly inside Phase 45 CR drafting.LocalAuthorizer) inside Loomworks that satisfies the protocol with hand-written logic. First version handles single-Operator delegation (Phase 45 scope); grows from there.LocalAuthorizer for OvaAuthorizer in Loomworks. The integration code doesn't change; only the implementation behind the seam does.Three commitments specifically should not bend under the pressure to ship integration testing quickly.
The seam (the Authorizer protocol) is what protects Loomworks from being coupled to whatever stub or implementation sits behind it. Without the seam, the stub leaks into Loomworks code paths and the eventual OVA-proper migration becomes a refactor rather than a swap. The discipline is to define the seam first, always, even when the stub is barely more than a function call.
The temptation when a stub starts working well is to invest in it as if it were the thing. Resist that. The stub exists to teach the contract, not to be the contract. When the stub starts wanting to grow features that aren't in the OVA contract direction, the discipline is to ask whether the feature belongs in the contract or in Loomworks itself, not in the stub.
The deployment-strategy work raised cross-instance authorization (jurisdiction credentials, "prove data never left German soil") as load on OVA. The temptation to build a stub that handles cross-instance authorization quickly should be resisted — that work is OVA-proper work, not stub work. The stub should answer the cross-instance call (returning a placeholder credential) but not pretend to enforce cross-instance authorization. Pretending invites Loomworks code paths to trust the stub for something the stub cannot actually deliver.
The memory-space-extensibility investigation §6.2 filed an open question about whether Phase 45 CR scope should anticipate OVA's load growth or only address the present case. This investigation sharpens the question:
Authorizer protocol) must anticipate enough of the load growth to be stable across multi-Contributor, multi-space, and agent-fabric extensions, or it will require breaking changes downstream. So the seam should be designed against the long-term contract, even if the stub behind it answers only the short-term needs.This split is the answer to the Phase 45 scope question raised in the prior investigation.
The OVA spec is the artifact the provisional patent attaches to. As Loomworks's stub teaches the contract, the spec evolves; as the spec evolves, the IP claims may need to evolve too. Worth filing as an IP-strategy question separate from this investigation: how do spec evolution and patent claim language stay in sync as Loomworks's stub experience refines the contract?
The progression from Option E (hand-written) to Option C (macaroons) is triggered by internal pressure from the stub, not by a calendar date. What does that pressure look like? Likely: the moment when the hand-written logic starts hand-rolling attenuation, or when delegation chains start requiring caveat-on-caveat handling. Worth flagging so the migration isn't missed when the moment arrives.
When a FORAY anchor fails (network issue, Kaspa congestion, FORAY service unavailable), what does Loomworks do? Three plausible answers, each with consequences:
The right answer is probably action-class-specific — high-stakes commits block; routine reads don't anchor at all; bulk operations may use the eventual-consistency path. Worth filing for when the FORAY integration surface is specified.
The most valuable output of running a stub is the catalog of authorization questions Loomworks actually asks. That catalog is the input to OVA's spec hardening. Worth treating the stub's API surface as a document — every call Loomworks makes against the stub is a data point about what OVA proper must answer. Periodic snapshots of the stub's surface should feed into the OVA spec project.
The Authorizer protocol is small enough to be a clean deliverable inside Phase 45 CR scope. The protocol definition, the LocalAuthorizer first implementation, the integration into the delegation contract code — all together a tractable Phase 45 addition. Worth surfacing in Phase 45 CR drafting as an explicit scope item rather than letting it land implicitly.
Deferring FORAY wire-in until multi-Contributor work enters the build is a deliberate scheduling decision worth recording. When Phase 45 is being scoped, the FORAY question will likely come up — "should we wire in FORAY now while we're touching the auth layer?" — and the answer is no, because the load that justifies the complexity tax isn't yet present. Recording the rationale here makes the eventual decision easier to defend.
If the OVA spec lives in its own project, it needs to be created. This is a separate workstream from Loomworks's build and probably from DUNIN7's immediate priorities (Loomworks build dominates), but the spec project's creation is the gating event for OVA's eventual implementation. Worth flagging as a queued direction with a target arc — probably after Arc 2 closes (Companion brain done) and before Arc 3 starts (Operator Layer frontend).
The Option E → Option C progression is worth treating as a soft architectural commitment, not a free choice that may go either way. The reasoning:
Worth recording the progression so it is not re-litigated each time the question comes up.
When LocalAuthorizer is replaced by OvaAuthorizer, the stub doesn't necessarily disappear — it may continue to exist as a development-mode authorizer (no network dependency, no Kaspa, runs locally in tests and CI). This is a good outcome; it means CI doesn't depend on Kaspa availability and dev cycles stay fast. Worth noting that the stub can survive OVA proper's deployment, just demoted from production placeholder to development convenience.
This investigation is the fifth in a coherent session-long arc:
The first four investigations surfaced questions that this fifth investigation answers in concrete terms:
Authorizer protocol; the stub answers them; OVA proper answers them eventually.Authorizer protocol.Authorizer protocol; FORAY anchoring lands when multi-Contributor work does.The session has produced what reads as a coherent plan: how Memory flows (closed-loop, elevation), where Loomworks sits in the market (AIF comparison), how authority scales (memory-space-extensibility), and how to land the substrate that makes the authority scaling work (this investigation). Each investigation depends on the prior ones; the five together form a unit.
This investigation was produced through a single-turn response to the Operator's three-part question, with the prior four session investigations as the substrate. The response decomposed the three questions into their sub-questions, walked the FORAY-OVA asymmetry, surveyed the stub options, and emerged with a six-step integration plan plus the project-boundary recommendations.
The trajectory worth preserving for future work: the conversation moved from "when do we integrate" (a timing question) to "what does the contract look like" (a specification question) to "where do the artifacts live" (a project-boundary question), with the recognition that contract clarity is the gating constraint and contract clarity comes from running a stub. The stub-progression pattern (Option E → Option C → OVA proper) is the strongest concrete commitment in this investigation; it should not be re-litigated each time the question comes up.
The OVA-as-load-following observation from the memory-space-extensibility investigation, combined with the substrate-readiness asymmetry between FORAY and OVA, made the integration plan tractable. Without the load-following framing, the question "when do we integrate OVA?" reads as a calendar question; with it, the question reads as a contract-clarity question, and the answer follows.
Five investigations across one session is a meaningful body of Discovery work. Each one preserves a trajectory; together they form a coherent map of how Loomworks's architecture extends from its present state into the multi-Contributor, multi-space, multi-instance, multi-agent future. None requires methodology revision. None forces a near-term phase change. All are input to future CR drafting and methodology evolution, with the strongest near-term implication being the Phase 45 CR scope sharpening filed across investigations §6.2 (memory-space-extensibility) and §7.1, §8.1 (this investigation).
The session also surfaced a meta-observation worth recording: the methodology has the structural answers; the build is at the simplest case; the work is in connecting structural answers to build sequencing. Each of the five investigations does that connecting work for a different domain. Together they suggest the next phase of methodology maturity is not new structural answers but integration plans — concrete sequences for landing what the methodology already commits to.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks — FORAY/OVA Integration Strategy Investigation — v0.1 — 2026-05-08