Data Pool: shared sources, separate scopes

01 · Prepare all three layers

Review/install the Forge data-pool Pack. Separately install Meilisearch/the service and configure endpoints, credentials and storage. Then select runtime capabilities, bind operation credentials and grant pool permissions. Pack installation does not create a search server, import company data or grant an agent.

Human → Nest operator interface → Data Pool service
Soot → Selected capability + own operation credential + pool grant → Data Pool service
Data Pool service → Indexed backend (Meilisearch)
Data Pool service owns document metadata, pool grants and mutation receipts.
Host owns tool bindings, provider keys and durable conversations.

A remote shared service can serve local and VM hosts. A direct single-host deployment has its own reviewed policy ownership. Compare endpoint, namespace, pool ID and policy; same-named pools on separate bindings are not automatically shared or synchronized.

02 · Human management is not a model run

In Data Pool, choose the management runtime and manager interface. Contextual sidebars list pools; compact layouts use a selector. Nest uses an empty setup conversation for authorized interface calls. Add/edit/delete/search does not submit a message or call a model. The runtime operator bearer controls the interface; an asserted “operator” username grants nothing.

Configure distinct DATA_POOL_UI according to the Pack guide. UI credentials cannot impersonate an agent; agent credentials cannot impersonate a human operator. Explicitly select the manager's configure capability.

03 · Three layers of permission

These are illustrative configured roles, not installed defaults. Every operation needs all three layers.

Support's read denial tests pool authorization, not a missing tool. A pool grant cannot add a capability or credential. Host administrators differ from pool grantees and cannot be revoked in the pool UI. Inspect effective scopes after changes; actor labels do not authenticate callers.

04 · Create a TEST brand-guide

Copy these fields into a disposable pool you own. This is TEST DATA for a fictional brand, not Soot product policy or a real support promise. The service assigns the current revision; do not type a fabricated revision.

ID: brand-guide
Source URI: urn:example:brand-guide
Title: Pebble Studio — TEST brand guide
Tags: test-data, brand-guide
Body:
TEST DATA ONLY — fictional Pebble Studio, not Soot product policy.
Brand voice: calm, plain and helpful. Use short sentences and concrete examples.
Avoid hype, invented features and guaranteed outcomes.
Test support fact: Pebble Studio replies to support requests within 24 hours.
The 24-hour window is TEST DATA, not a real service commitment.
Drafts require human review. Do not publish or modify this guide.

1. As an authorized Human, open Data Pool, select the intended runtime and DataManager interface, and create a disposable pool (for example, docs-test). Record its actual ID/generation.
2. Create a text/Markdown document: enter ID brand-guide, title and body above. Set its source URI to urn:example:brand-guide and add the two tags. Save; inspect the service-returned source URI, document ID and current revision. If a build assigns IDs, use the returned ID rather than pretending your requested ID was saved.
3. In the pool's grants, grant Marketing read only using its host-reported identity. Confirm its selected read capability and own bound credential on the host. Do not grant write/manage/publication; Support retains NO pool grant.
4. In Soots, select Marketing, save/activate the reviewed mission and confirm active revision. Open Test and replace the revision placeholder below with the service-returned value.

Read TEST DATA from urn:example:brand-guide, document brand-guide,
revision [current service revision] in the granted test pool.
Report source URI/ID/current revision from the read result.
Summarize the fictional brand voice and its 24-hour test support window.
Draft three short posts. Label test facts TEST DATA, not Soot product policy.
Do not write, publish, run shell or add permissions.
Stop if the source is missing, inaccessible or differs from the requested revision.

Expected evidence—not a fabricated response—is the real source URI/ID/current revision, calm/plain/helpful voice, the correctly labeled 24-hour test fact, cited drafts and no write or publication. For a file/Skill alternative, use its actual filepath plus a reviewed Git commit/hash/version, not invented pool IDs or revisions.

05 · Check the real call and denied write

Open the actual Test conversation/run detail. Check active config revision, real provider/model attempt and completion state. Inspect tool history for read_skill where used and a successful data-pool_query read of this document; compare the returned URI/ID/revision and facts with the saved document. Check pool activity for the same caller and read. A read receipt alone does not prove the answer used the source; review the answer too. Human creation and grants are not model calls.

To prove denied write, an operator uses an authorized disposable permission fixture with a selected write operation and its own bound credential, while Marketing's pool grant stays read only. Attempt a harmless edit to a disposable document, expect DENIED, and reread to confirm content/revision unchanged. If no write tool is selected, that refusal proves only tool scope, not pool write denial. Do not temporarily widen a real Marketing configuration merely to run this check; use a separate fixture configured for the test.

With Support's selected read capability and its own bound read credential but NO pool grant, read must be DENIED. After revoking the fixture's read grant, read must also be denied. Keep the original request/receipt for uncertain outcomes; never retry an unknown write using a new ID. These are steps to execute and inspect, not claims of tests already run by this guide.

06 · Source versions and conflicts

For Data Pool, record source URI/URN, document ID, current revision, pool generation, policy, actor and provenance. Search is typo-tolerant, accent-insensitive and index-backed; verify ID/revision rather than treating the first result as the approved source. Public URL imports reject internal addresses; content remains text, not executable instructions. Activity is a limited window, not a full historical content archive.

A typical conflict: Human reads v1 → scoped manager runner writes v2 → stale Human save conflicts and retains the draft → Human reads v2, reviews and explicitly rebases to save v3. Runner writes are not LLM-created content. Another concurrent write may conflict again. If a response is uncertain, check the original request's status. Recovery retains only binding/request metadata, not credentials or document contents; recovered requests are check-only.

07 · An observed review · 2026-10-09

A separate review on a custom Service host used DataManager, Marketing and Support. Marketing's mission was saved and activated. A real Test used openai-codex/gpt-6-luna, called read_skill and data-pool_query, and read brand-guide revision 3 with its source URN. These are dated observations, not default providers or preinstalled configuration; the copyable TEST fixture above is a practice input, not that run's response.

Human v1 → scoped manager RUNNER v2 (not model) → stale Human conflict with draft retained → explicit Human rebase v3. Marketing read was allowed and write DENIED. Support had a selected read capability and its own bound read credential, but NO pool grant; its read was DENIED. Forged actors and UI/agent credential confusion were DENIED. Human management recorded zero model calls.

One run observed 17.9 seconds execution and 38.6 ms queue time. This single observation is not a performance promise. Unknown USD stayed unknown.