Paste-Driven Provenance Archive

What this is

A workflow for building a structured, trustworthy reference library out of source material that a person can access but an agent cannot — a paywalled database, an authenticated internal system, a session-gated portal, or any source where automated scraping would be unreliable, against terms of use, or simply unavailable. The person retrieves each item manually from their own authorized access and pastes it into the conversation, one item at a time, in a tight loop. The agent's job is narrow and repeatable: take the paste, write it to a standalone file using a fixed template that preserves exactly where it came from and when, log it in a running index, and wait for the next paste. No fetching, no scraping, no navigating on the person's behalf — the agent is the archivist, not the retriever.

Run at pace, this produces a large, consistent, fully-provenanced reference corpus — dozens or hundreds of items — built entirely from material the agent never touched at the source, with a paper trail proving exactly where every item came from.

Why this exists

Some source material genuinely can't be pulled by an agent, for reasons that have nothing to do with the agent's technical capability: the source sits behind a login the agent doesn't have, the service's terms of use restrict automated access, or the retrieval itself needs a human's judgment about which of several similar-looking versions is the current, correct one. In these situations the honest move isn't to quietly work around the restriction — it's to make the human the retrieval step and give them a system that makes repetitive pasting fast, consistent, and low-friction instead of a manual chore they have to reinvent each time.

The alternative — a person pasting raw text into a chat and hoping to remember later where it came from — loses the two things that make a reference archive actually usable months later: where each item came from and when it was current. A fixed template forces both to be captured every single time, without the person having to remember to ask for it.

This also solves a narrower but real problem: an agent asked to scrape a login-gated source will sometimes have the technical means to do it (browser automation, computer use) even when doing so isn't the right call. Naming this pattern explicitly — the agent archives, the person retrieves — removes the ambiguity before it comes up mid-session.

Relationship to FTR-32 (Cowork Orchestrated Research)

Not a dependency, and not the same mechanism — worth being explicit about the difference rather than letting the two blur together. This feature is deliberately paste-driven: the person is always the one crossing the access boundary, and the agent never attempts retrieval, even when technically capable of it. FTR-32 is the opposite in one specific respect — it hands Cowork a batch of items to actually go fetch, for sources Cowork can legitimately reach.

If a source turns out to be reachable through Cowork's own browsing (a public site needing iterative navigation rather than a login, for instance), FTR-32 may be the better fit for that specific source, not this feature. The two could plausibly work together — Cowork retrieving what it can reach, this feature's template and index handling what only a person can retrieve — but that combined workflow isn't specified here. If that's wanted as a real capability, it deserves its own proper spec (either as an FTR-32 extension or a new feature) rather than being guessed at inside this one.

The core loop

1. Person pastes one source item (a document, a record, a listing, a statute, a page) into the conversation, from their own authorized access.
2. Agent immediately writes it to a new file using the fixed template (see below) — no batching, no waiting for a batch of pastes.
3. Agent logs the new file as a row in the running index.
4. Agent reports a short confirmation and waits for the next paste.
5. Repeat until the source category is exhausted or the person stops.

Nothing about this loop is agent-initiated. The agent never asks "what's next" in a way that implies it could go get it — the person drives every retrieval, and the agent's only job between pastes is filing and indexing.

The item template

Every filed item is a standalone markdown file with the same fixed sections, regardless of what kind of source material it is:

# [Item ID / Citation] — [Short Title]

## Verbatim Content
[The pasted material, reproduced exactly as retrieved — no paraphrasing,
no summarizing, no silent edits. If the source includes both primary
content and secondary annotation/commentary, only the primary content
goes here — see "Annotation handling" below.]

## Source
[Where this came from: platform/database name, and the date the person
retrieved it — always the person's retrieval date, never assumed.]

## Currency
[Whatever tells a future reader whether this is still current: a
version number, a last-updated date, an edition, a revision history —
whatever the source itself provides for this purpose.]

## Summation (agent's own words — NOT verbatim source text)
[A plain-language synthesis of what this item says and why it matters,
written by the agent, never copy-pasted from the source's own commentary
or annotations. Always explicitly labeled as non-verbatim so a reader
can never mistake this section for primary source material.]

## Relevance / Application
[Why this item matters for the actual project — flagged prominently if
this is a high-priority ("KEY") item, or noted as low-relevance/
retained-for-completeness if it's peripheral. This is the section that
turns a pile of filed documents into an actually navigable library.]

Annotation handling. Many real-world sources bundle primary content with secondary commentary — case annotations on a statute, editorial notes on a record, related-links sidebars. The primary content goes into Verbatim Content exactly as retrieved. Secondary commentary is never reproduced verbatim; if it's genuinely useful, its substance gets folded into Summation in the agent's own words, with enough attribution (a case name, a source name) that a reader could trace it back if they needed to verify it directly.

The prerequisite: a directory and a target list

Before the loop starts, two things need to exist:

A destination folder, dedicated to this archive and nothing else. Flat is usually fine for a small archive; a folder-per-category structure works better once the archive crosses roughly 30–40 items, mirroring however the source material is naturally organized (e.g., a folder per statute title, a folder per record type).

A target list or scope statement — even a rough one. This can be as loose as "everything under this heading in the source" or as tight as a numbered checklist of specific items to retrieve. The point of having it isn't rigid completeness tracking (see the index below for that) — it's giving the person something to work down from, so the loop has a natural end rather than trailing off unresolved.

Both of these are worth confirming explicitly before the first paste, rather than assumed — see Ask, only if needed below.

The running index

A single markdown file at the archive's root, updated as items are filed — not necessarily after every single paste if the person is pasting in a fast burst, but synced at natural pauses and always before ending a session. One row per item:

Status values:

• Indexed — appears in the source's own table of contents / listing, not yet retrieved
• Pulled — filed to disk with the full template
• KEY — pulled and flagged as high-priority/directly relevant (use as a suffix on Pulled, e.g. "Pulled — KEY")

Above the table, a running narrative status block by category — not just the raw row count — makes the index skimmable at a glance without reading every row: which categories are complete, which are open, and a one-line pointer to anything flagged KEY within each.

A status summary line at the very top of the file, kept current: total items tracked, total pulled, and what (if anything) is still open. This is the one line a person can read to know the archive's state without opening the table.

Handling drift, gaps, and misfires

Real sessions don't run perfectly straight through a target list. A few patterns worth planning for:

• A pasted item turns out to be from a different part of the source than expected (wrong chapter, wrong category, a cross-reference the person didn't intend to pull yet). File it correctly based on what it actually is, not what was expected — note the mismatch plainly, and ask the person whether to resume the original sequence or follow the new thread.
• Divider or table-of-contents pages get pasted (a section header with no operative content). These are worth indexing as a placeholder row so the sequence isn't confusing later, but don't need a full templated file — a one-line "Indexed (divider only)" row is enough until the real content arrives.
• The index falls behind the actual pulls during a fast paste burst. This is expected, not a failure — resync deliberately at a natural pause rather than trying to keep perfect real-time parity, and double-check row counts against actual pulled-file counts when resyncing rather than trusting a running mental tally (miscounts compound quickly in a large batch update).
• A question comes up about whether the agent could just go get the rest itself. If the person asks this directly, answer honestly: if the agent has the technical means (browser tools, computer use) to reach the source, say so plainly rather than claiming inability — but explain that this workflow is a deliberate choice to keep the person as the authorized retriever, both for the provenance chain and for respecting the source's terms of use, and hold that position unless the person has a genuinely different authorization structure in mind.

Assess first

• Confirm a destination folder exists (or agree on one) before the first paste arrives.
• Confirm there's at least a rough target list or scope — full completeness isn't required, but an open-ended "paste whatever, whenever" without any organizing scope makes the index much less useful later.
• Check whether an index file already exists for this archive; if so, read and carry it forward rather than starting fresh.
• If a related tracker system (Document Tracker, FTR-13) is already installed in the project, register this archive's index as one of its tracked artifacts rather than running two disconnected systems.
• If the source might actually be reachable through Cowork's own browsing rather than genuinely agent-unreachable, flag that — see Relationship to FTR-32 above — this feature is the right fit specifically when the source can't be reached automatically, not just when it happens to be more convenient to paste.

Ask, only if needed

• "Where should this get filed?" — if no destination folder has been named yet.
• "Do you have a target list, or are we pulling as you go?" — establishes whether to expect a bounded or open-ended loop.
• When a pasted item doesn't match the expected sequence: "This looks like it's from [X] instead of [Y] — want me to file it as-is and note the mismatch, or go back to the original sequence?"
• Periodically, if the archive has been running a while: "Want a status check on what's pulled versus what's still open?" — surfacing this proactively rather than waiting to be asked keeps a long-running archive from silently stalling.

Write

1. Confirm the destination folder and (rough) target scope before the first paste.
2. On each paste: write the item to its own file using the fixed template — Verbatim Content, Source, Currency, Summation (own words, explicitly labeled), Relevance/Application.
3. Never reproduce secondary annotation/commentary verbatim — fold its substance into Summation only, with attribution.
4. Add a row to the running index; flag KEY items explicitly and explain why in the Relevance/Application section.
5. At natural pauses (not necessarily after every paste): resync the index's summary line and category status blocks against the actual filed-file count.
6. Report a short confirmation after each file and wait for the next paste — never ask the archive to be "finished" on the agent's own initiative.
7. If asked whether the agent could retrieve the remaining items itself: answer honestly about technical capability, and explain the deliberate reasons for keeping retrieval human-driven.

Add this section to admin\AGENT_INSTRUCTIONS.md:

◆ PASTE-DRIVEN PROVENANCE ARCHIVE

Archive folder: [path]
Target scope: [rough description or explicit list]
Index file: [path]\_[ArchiveName]_INDEX.md

THE LOOP
1. Person pastes one source item, retrieved from their own authorized
   access — the agent never fetches, scrapes, or navigates the source
   itself, even if technically capable of doing so.
2. Agent files it immediately as its own markdown file using the fixed
   template: Verbatim Content · Source · Currency · Summation (own
   words, explicitly labeled non-verbatim) · Relevance/Application.
3. Secondary annotation/commentary bundled with the source material is
   NEVER reproduced verbatim — only synthesized into Summation, with
   attribution.
4. Agent adds a row to the running index and flags KEY items explicitly.
5. Agent reports a short confirmation and waits for the next paste.

INDEX MAINTENANCE
- Top-of-file status summary line: total tracked / total pulled / what's
  open — kept current at natural pauses, not necessarily after every
  single paste.
- Narrative status block per category, not just raw table rows.
- Resync deliberately at pauses; double-check row counts against actual
  filed files rather than trusting a running tally.

DRIFT HANDLING
- Mismatched paste (wrong category/section): file it as what it actually
  is, note the mismatch, ask whether to resume the original sequence.
- Divider/TOC-only pastes: one-line "Indexed (divider only)" row, no
  full templated file needed until real content arrives.
- If asked whether the agent could just fetch the rest itself: answer
  honestly about technical capability, then explain this is a
  deliberate workflow choice (provenance-chain integrity + respecting
  the source's terms of use), not a limitation — and hold that position
  unless the person changes the actual authorization structure.

NOT THE SAME AS FTR-32 (Cowork Orchestrated Research, if installed):
  FTR-32 has Cowork actually retrieve reachable sources; this feature is
  for sources an agent genuinely cannot reach. Don't reach for this
  feature's paste loop just because pasting feels easier than kicking
  off a Cowork batch for a source Cowork could actually reach.

Confirm

Confirm: the destination folder and index file are set up, the item template is understood, and the target scope (even if rough) is agreed. Ready for the first paste whenever the person has it.

Appendix: original prompt this was generalized from

The following is representative of how this workflow was actually kicked off in its originating session (legal casework — building a verbatim Georgia statute library from LexisNexis). Included here as a concrete worked example, not as the only valid way to invoke this feature. Case name and internal tracking reference below are de-identified placeholders, not the actual matter this was built from.

ABC-R08 — PART B · STATUTE LIBRARY BUILD (PASTE-DRIVEN LOOP)

We're building a reference library of verbatim statutory text to support this case. Here's how it works: I have my own authorized access to [source]. I'll retrieve each statute myself and paste it to you here, one at a time. When I paste one, immediately write it to disk with full provenance — where it came from, when I pulled it, and its own currency/amendment info — using our standard template: Verbatim Text / Source / Currency / Summation (your own words, clearly NOT verbatim) / Application to this case. Then wait for the next paste.

Do not go fetch these yourself, even if you're technically able to — I want to control retrieval and keep a clean paper trail of exactly what I pulled and when. If a statute's text includes case annotations or commentary, don't reproduce those verbatim — you can describe relevant case law in your own words in the Summation or Application sections, with case names cited, but the annotation text itself doesn't get copied in.

Flag anything genuinely important to the case as a KEY STATUTE. Keep a running master index as we go, and sync it periodically so it stays accurate as the pace picks up.

Target folder: [path]. Starting target list: [chapter/section range or description]. Let's start — I'll paste the first one now.

End of feature draft — generalized 2026-07-12 from a de-identified statute library build (case name and tracking reference replaced with generic placeholders; Georgia/LexisNexis context retained as non-identifying background). Not legal-specific; applicable to any archive built from an access-controlled or agent-unreachable source.