CAFE Y4: AI-Informed Support for CAFE Dataset Deposit

[cmbz]

Overview

• Provide AI-informed support for dataset deposit to CAFE collections. AI-support (e.g., via agent templates or code) that CAFE contributors can embed in their dataset deposit workflows that ensure deposits meet Harvard Dataverse requirements and CAFE curation best practices.
• Support could take the form of agents.md or skill.md files, scripts, or external tools.
• Note:
  • skill.md files: "A skill.md file is a standardized, machine-readable Markdown file used to extend the capabilities of AI coding agents. It serves as a structured "playbook" or recipe book, providing AI agents with persistent, step-by-step procedural workflows for specific tasks without polluting or bloating the AI's core context window when the skill is not in use"
  • agents.md files: "An agents.md file is an open-standard Markdown file placed at the root of a software repository to provide persistent, project-specific guidance directly to AI coding tools. It essentially acts as a 'README for AI agents' onboarding tools like Claude Code, Cursor, Windsurf, GitHub Copilot, and Aider to your exact stack, rules, and workflows."

Proposed Development

Deposit packaging agent (for large data)

• Tools to provide users with data organization and packaging recommendations enabling a smooth deposit into a Harvard Dataverse collection using NESE tape or disk storage.
  • Inputs: read-only access to a user's dataset directory (e.g., on their laptop)
  • Example Workflow: user asks Claude (or other LLM) to use CAFE-related skill.md and agents.md to analyze their dataset directory and recommend a file layout for deposit into a NESE tape or disk dataset.

Deposit Harvard Dataverse and/or CAFE compliance agent

• Tools to review and verify that users' dataset deposits meet Harvard Dataverse and CAFE deposit requirements (e.g., have required metadata, documentation, number of files, appropriate file packaging)
  • Inputs: read-only access to a user's dataset on Harvard Dataverse
  • Example Workflow: user asks Claude (or other LLM) to use Harvard Dataverse and/or CAFE-related skill.md and agents.md to verify their dataset and recommend improvements (e.g., additional metadata or documentation).

Deposit assistant agent

• Tools to bypass the Harvard Dataverse UI and instead deposit users' datasets directly using AI workflows and scripts.
  • Inputs: read-only access to a user's dataset directory (e.g., on their laptop)
  • Example Workflow: user asks Claude (or other LLM) to use Harvard Dataverse and/or CAFE-related skill.md and agents.md to create a valid dataset and deposit to a Harvard Dataverse collection.

Deposit README creator agent

• Tools to enable users to automatically generate README files for their dataset deposits
  • Inputs: read-only access to a user's dataset directory (e.g., on their laptop), dataset draft on Harvard Dataverse, and/or related publications and documentation
  • Example Workflow: user asks Claude (or other LLM) to use Harvard Dataverse and/or CAFE-related skill.md and agents.md to create a draft README for the dataset.

Requirements

• Rules, requirements, and examples for each use case of Good, Okay, and Poor (we can draw on examples gathered by the HDV curation and production teams to inform spam detection)

Challenges

• Handling edge cases

[rtreacy]

Preliminary plan / questions before scoping this further

Thanks for filing this — before committing to an implementation approach for the proposed agents, I looked at what already exists in Dataverse/dataverse-pm to build on, plus the "Customization and Improvement of Dataverse for the CAFE Project" doc linked from #161. Sharing what that tells us and where I think there's still a gap. (Note: the issue has since grown a fourth agent — the README creator — which I've folded in below too.)

What the CAFE requirements doc tells us

The doc is mostly about custom metadata blocks, which the CAFE team explicitly prioritized as the first area of focus:

• Keywords via a controlled, NIH-provided glossary, ideally as a dynamically-updating dropdown (the doc floats using Dataverse's "Controlled Vocabulary URL" field feature to load terms from a CSV).
• Geospatial metadata: polygons, spatial reference systems, and support for multiple geographic administrative levels per dataset (not just one).
• A field-by-field audit against a "CAFE Dataverse Metadata Requirements.xlsx" to mark each field required/optional/hidden.
• A proposed codebook/data-dictionary step for tabular uploads (.parquet, .rds, etc.), ideally linking column names to controlled vocabularies.
• An open question the CAFE team was already asking themselves: whether metadata schema linkage (topics/keywords) should be automated vs. manually curated — directly relevant to why an "AI-informed" approach is being proposed here.
• Cloud storage integration (AWS/NERC) for larger datasets is mentioned as a separate, lower-priority item — this is the closest thing to a stated need for the "packaging agent," but it's not developed in any detail in the doc.

Update: dataverse.harvard.edu#400 is done and the relevant metadata has been loaded. That issue shipped a custom CIESIN Metadata Block (FGDC-standard geospatial fields — Horizontal Coordinate System Definition, Geodetic Model, Direct Spatial Reference Method, Spatial Data Organization Information, etc.) enabled on the SEDAC collection, with data migrated in. That's real, concrete progress on the "Geospatial Metadata Challenges" theme above — but it's scoped specifically to CIESIN/SEDAC, not a CAFE-wide geospatial solution, and notably the field owner confirmed during that work that none of the new fields need multiple values, which is the opposite of the "multiple geographic administrative levels" goal in the broader CAFE doc — so that broader ask still looks open. The NIH keyword-vocabulary dropdown, the CAFE-wide required/optional/hidden field audit, and the codebook/data-dictionary step don't appear to be covered by #400 and still need a status check.

This does give us a strong, concrete pilot target for Phase 1, though: SEDAC now has a live, populated custom metadata block we could validate a compliance agent against right away, rather than waiting on the CAFE-wide metadata work.

Related: dataverse-pm#568

dataverse-pm#568 is investigating the general (not CAFE-specific) feasibility of agents.md/skill.md researcher-workflow templates for any Dataverse installation, and it's directly relevant to how we should shape #595's proposed agents:

• It defines a concrete template structure — Requirements → Actions → Validation → Scoring — with a worked example ("Quantitative AI-Ready Data Deposit") that lists file-format/size/metadata requirements, the actions to take (create sub-collection → create dataset → upload files), and two validation/scoring passes: a "standard method" and a FAIRSCAPE AI-readiness method.
• I read the FAIRSCAPE paper (bioRxiv 2024.12.23.629818) to get past the name. It's a real, published, NIH Bridge2AI-funded framework (same NIH ecosystem as CAFE), built with 17 institutions, that operationalizes 28 AI-readiness criteria across seven axes (FAIRness, Provenance, Characterization, Pre-model Explainability, Ethics, Sustainability, Computability). It's not a single pass/fail score — evaluation is an automated, per-criterion presence/completeness histogram computed from RO-Crate 1.2 / JSON-LD (schema.org + W3C PROV/EVI provenance, Gebru-style Datasheets, Frictionless/LinkML, optional Croissant) metadata packages.
• This isn't just conceptually related — FAIRSCAPE already deposits into a Dataverse instance. The paper describes direct upload from FAIRSCAPE into the University of Virginia Dataverse (another NIH GREI-network repository) for its CM4AI datasets, via an open-source, pip-installable FAIRSCAPE CLI (Apache 2.0, on Zenodo/GitHub) that builds the RO-Crate/JSON-LD package. That's real prior art for the "Actions" half of a Investigate feasibility of developing agents.md and skill.md Dataverse workflow templates for researchers #568-style template (create dataset, upload files) — worth evaluating whether we can call the actual FAIRSCAPE CLI rather than reimplementing packaging or scoring ourselves.
• The paper also names a concrete, relevant gap: "there is no mechanism to view our detailed metadata in Dataverse, other than viewing release-level information." FAIRSCAPE's rich provenance/AI-readiness metadata doesn't currently surface inside Dataverse's own metadata blocks/UI — Dataverse only sees a generic release record. That's the same shape of problem TG: Metadata Task Group #400 solved for CIESIN/SEDAC (a custom metadata block to hold domain-specific structured metadata) — a "FAIRSCAPE AI-readiness" custom metadata block or export format is a plausible, scoped answer to the "Scoring" section of a Investigate feasibility of developing agents.md and skill.md Dataverse workflow templates for researchers #568-style template, rather than trying to reproduce FAIRSCAPE's own evaluation logic in Dataverse.
• Mapping this onto CAFE Y4: AI-Informed Support for CAFE Dataset Deposit #595's three proposed agents: our in-progress Phase 1 compliance agent is essentially the "Validation" (standard method) piece of a template shaped like Investigate feasibility of developing agents.md and skill.md Dataverse workflow templates for researchers #568's example — it already reports pass/fail against a collection's schema. The Actions section (create sub-collection/dataset, upload files) has real prior art in the FAIRSCAPE CLI to build on rather than starting from scratch; the Scoring section (Dataverse completeness + FAIRSCAPE AI-readiness) looks more like "surface FAIRSCAPE's own output in Dataverse" than "reimplement FAIRSCAPE's scoring."
• Given the overlap, it'd be worth framing CAFE Y4: AI-Informed Support for CAFE Dataset Deposit #595's CAFE/SEDAC agents as the CAFE-specific instantiation of Investigate feasibility of developing agents.md and skill.md Dataverse workflow templates for researchers #568's general template pattern, rather than parallel, independently-designed efforts — otherwise we risk two different agents.md shapes for the same underlying idea, and possibly duplicating work FAIRSCAPE has already done.

Related: prior art for the "Deposit README creator agent"

The issue's newer Deposit README creator agent asks for a tool that reads a user's local dataset directory, a Dataverse dataset draft, and/or related publications, and drafts a README via a skill.md/agents.md-guided LLM workflow. Two existing tools are relevant, but neither is actually that:

	scholarsportal/README-generator-prototype (Borealis)	URGE (USN University Library, Norway)
Reads a Dataverse dataset	✅ via standard REST API	✅ explicitly supports Dataverse drafts
Reads a local dataset directory	❌	❌
Reads related publications	❌	❌
LLM/skill.md-driven	❌ — standalone Next.js web app	❌ — standalone hosted web app/form
Open source	✅ (TypeScript, no LICENSE file yet — worth flagging if reused)	❌ closed, hosted-only
Integration mechanism	Registered as a Dataverse External Tool (dataset-level "configure" tool) — the same officially-documented mechanism Dataverse already supports for third-party dataset tools	Own hosted app; exports back to DataverseNO
Scope	Dataverse-only input; mechanical metadata/file-list → README population; Minimum/Advanced modes, custom sections, saves result as a dataset file	Broader: Dataverse, Figshare, Zenodo, Norwegian DMP systems (Sikt DMP, ELIXIR-NO), prior README files; adds a FAIR-compliance file-checker, grammar checking, anonymized-README mode, and machine-readable JSON output
Maturity	Explicitly a prototype	v1.5, described as production

Neither fulfills the agent as specified — both are traditional web apps, not agent-orchestrated workflows, and neither touches local files or publications. But both meaningfully shrink the real work here: the hard part of a README agent is knowing which Dataverse metadata maps to which README section and what "good" looks like, and both tools have already solved that against live Dataverse metadata. Borealis's tool is the more directly actionable building block — open source and built on Dataverse's own External Tools framework, so a fork/adaptation (not a rewrite) could plausibly register against a CAFE collection. URGE is closed and Norway-infrastructure-oriented, so it's better as a reference for a thorough README-quality rubric (directly useful for the issue's own "Good/Okay/Poor examples" requirement) than as something to adopt directly.

Existing Dataverse building blocks

• GET /api/dataverses/{id}/datasetSchema + POST /api/dataverses/{id}/validateDatasetJson — a JSON-Schema-based validator (required fields, controlled vocab, typeClass rules) that runs before dataset creation. This is close to exactly what the "compliance agent" needs for the generic-HDV half of the job, and would automatically pick up the required/optional/hidden field audit once that's configured on the collection.
• The Curation Status API (/api/datasets/{id}/curationStatus, /allowedCurationLabels) was explicitly built "to integrate Dataverse with an external curation process/application" — a natural integration point for a compliance or assistant agent.
• File/size/count limits (:ZipUploadFilesLimit, :MaxFileUploadSizeInBytes, BagIt zip-size settings) and the Big Data Administration guide are the relevant reference material for the packaging agent, though that guide is currently admin-facing, not depositor-facing.
• No existing org convention for agents.md/skill.md files beyond one small ad hoc example in scripts/dev/release-dates/AGENTS.md — but Investigate feasibility of developing agents.md and skill.md Dataverse workflow templates for researchers #568 (above) now gives us a proposed Requirements/Actions/Validation/Scoring shape to align with, rather than inventing our own from scratch. Still worth deciding up front whether the deliverable should be Claude-specific (Claude Code skills) or provider-agnostic (plain docs/scripts any agent or human could use).
• Gap: there's no single "run a full compliance check" endpoint today — an agent would need to orchestrate a few API calls itself, and there's no API surface at all yet for "does this tabular file have a codebook/data dictionary."
• Dataverse's External Tools framework (dataset-level "configure"/"explore" tools) is the documented, supported way to register a third-party web app against a dataset — this is what Borealis's README generator uses (above), and it's a real option for a README agent regardless of whether we build on their code or write our own.

Proposed phasing

1. Phase 0: Confirm status of the remaining custom-metadata-block items (NIH keyword vocab dropdown, CAFE-wide required/optional/hidden audit, codebook/data-dictionary step) — done, in progress, or not started? Also decide the target deliverable format (Claude Code skill vs. provider-agnostic AGENTS.md/scripts vs. CI check).
2. Phase 1 — Deposit HDV compliance agent. Start here against validateDatasetJson/curation status for the generic-HDV requirements plus the now-live CIESIN metadata block, using SEDAC as the pilot collection since it already has a populated custom schema to validate against. Layer in the remaining CAFE-specific checks (keyword vocab, codebook presence) as each becomes available elsewhere in the schema.
3. Phase 2 — Deposit README creator agent. Underway on two complementary fronts, per the prior art above: a CAFE-adapted fork of Borealis's open-source README generator as a click-through Dataverse External Tool for UI-based depositors, and a Claude Code skill using the same field-mapping spec (not a runtime dependency on the fork) for agent-based ones. Doesn't block on Phase 0/1 metadata work the way the other phases do, since it only needs whatever metadata already exists on a dataset.
4. Phase 3 — Deposit assistant agent. A conversational layer that walks a depositor through metadata entry, calling the Phase 1 compliance agent as it goes — including surfacing the NIH controlled-vocabulary choices and geospatial-field guidance the CAFE doc calls out as confusing today.
5. Phase 4 — Deposit packaging agent (large data). Scoped around existing file/size/count limits, BagIt/S3/Globus guidance, and whatever comes out of the "Cloud Storage Integration" (AWS/NERC) discussion in the CAFE doc. Needs its own confirmation from CAFE stakeholders on which storage backend(s) are actually in play.

Questions

1. What's the current status of the remaining custom-metadata-block items — NIH keyword vocabulary dropdown, the CAFE-wide required/optional/hidden field audit, and the codebook/data-dictionary step? Has any of that shipped, or is TG: Metadata Task Group #400 the extent of it so far?
2. Is the "CAFE Dataverse Metadata Requirements.xlsx" field audit available anywhere I could reference directly?
3. Are CAFE contributors depositing via the API, the UI, or both? This affects whether the "compliance agent" is a pre-flight script/CLI or something embedded in the UI.
4. Should this target Claude Code skills specifically, or stay provider-agnostic?
5. Is SEDAC the right pilot collection to build Phase 1 against, or is there a different one already earmarked for Y4 testing?
6. Should CAFE Y4: AI-Informed Support for CAFE Dataset Deposit #595 explicitly coordinate with Investigate feasibility of developing agents.md and skill.md Dataverse workflow templates for researchers #568 on a shared agents.md template shape (Requirements/Actions/Validation/Scoring), or are they meant to stay separate efforts?
7. Is CAFE (or anyone at IQSS) already in contact with the FAIRSCAPE/Bridge2AI team? Given they've already built a Dataverse-deposit pipeline with AI-readiness scoring, it may be worth reusing/wrapping their CLI rather than reimplementing scoring logic independently.
8. Has anyone at IQSS talked to Scholars Portal/Borealis about their README generator? It's open source and built on Dataverse's own External Tools framework — worth knowing if they'd welcome a fork/collaboration before we duplicate that work for CAFE.

Progress:

• Phase 1 (compliance agent): a first pass is done — a standalone, dependency-free CLI (scripts/cafe-deposit-compliance/) that validates a dataset (a local draft JSON file, or an already-deposited dataset by persistent ID) against a collection's schema via Dataverse's own datasetSchema/validateDatasetJson/curationStatus APIs, piloted against SEDAC.
• Phase 2 (README creator agent): underway on both fronts described above.
  • A CAFE-adapted fork of Borealis's README generator (~/CAFE/README-generator-prototype, branch cafe-hdv-adaptation) — rebranded for Harvard Dataverse, publisher now read dynamically instead of hardcoded, and a new CIESIN Geospatial Metadata section added. Not yet deployed anywhere.
  • A Claude Code skill (.claude/skills/cafe-readme-generator/) that ports the fork's verified field-extraction logic into standalone Python rather than depending on it being deployed, and goes further than either Borealis's tool or URGE by reading a local dataset directory before anything's uploaded (the one input source neither of those tools support). Also adds three URGE-inspired capabilities, each independently implemented since URGE itself is closed-source: prior-README ingestion (carries forward free-text prose like Methodology from an earlier README), an anonymized/double-blind mode, and a FAIR-compliance file-naming/format checker. Ships both a Claude Code-specific SKILL.md and a tool-agnostic AGENTS.md variant for other coding agents.

The "Actions" (create dataset, upload files) and "Scoring" (Dataverse completeness + FAIRSCAPE AI-readiness) pieces of a #568-style template are still open, per above.

[rtreacy]

Design Doc: CAFE Y4 AI-Informed Support for Dataset Deposit

• Issue: IQSS/dataverse-pm#595
• Epic: CAFE Y4: Development Work #587 — CAFE Y4: Development Work (under IQSS/dataverse-pm#161)
• Related: IQSS/dataverse-pm#568 — general (non-CAFE) agents.md/skill.md template feasibility study; IQSS/dataverse.harvard.edu#400 — CIESIN metadata block (done, live on SEDAC)
• Status: Draft / partial implementation. Phase 1 and Phase 2 have working proofs of concept; none has been tested against a live Dataverse instance yet.
• Author: TBD
• Date: 2026-08-20

1. Background

CAFE researchers increasingly use AI agents in their data workflows; HDV curators separately review every CAFE deposit for compliance. #595 proposes closing that gap with agents.md/skill.md templates (plus backing scripts) that CAFE contributors can use in their own deposit workflows, split into four agents:

1. Deposit packaging agent — recommends file layout/packaging for large-data deposits (NESE tape/disk), from read-only access to a local dataset directory.
2. Deposit Harvard Dataverse and/or CAFE compliance agent — reviews a deposited/draft dataset against HDV/CAFE requirements, from read-only access to the dataset on Dataverse.
3. Deposit assistant agent — bypasses the Dataverse UI, depositing directly via AI workflows/scripts, from a local directory.
4. Deposit README creator agent — drafts a README from a local directory, a Dataverse dataset draft, and/or related publications.

The issue also asks for a Good/Okay/Poor rubric per use case, and flags "handling edge cases" as an open challenge.

A sibling investigation, #568, is scoping the same idea generically (any Dataverse install, not CAFE-specific) with a concrete template shape — Requirements → Actions → Validation → Scoring — and its worked example names a FAIRSCAPE AI-readiness score as one validation/scoring method. FAIRSCAPE (bioRxiv 2024.12.23.629818) is a real, NIH Bridge2AI-funded framework that already deposits into a sibling GREI Dataverse instance (UVA) via an open-source CLI — real prior art for the "Actions"/"Scoring" pieces, not something to reimplement blind. See §9 on whether/how to coordinate with #568 rather than duplicating it.

2. Clarifying scope: skill.md vs agents.md, and CAFE-specific vs general (#568)

The issue's own definitions (quoted in its body): a skill.md is a lazy-loaded, tool-specific "playbook" (Claude Code's mechanism specifically); an agents.md is the open, cross-tool standard (Claude Code, Cursor, Windsurf, Copilot, Aider). Every deliverable below ships both — a Claude Code SKILL.md for discovery/auto-loading, and a plain AGENTS.md with no frontmatter or Claude-specific tool names, so the same workflow runs under any agent that can execute a shell command. The backing scripts themselves are always plain, dependency-free Python — the actual portable core, not the markdown wrapper.

#595 is the CAFE/SEDAC-scoped instantiation; #568 is the general pattern. Recommend treating #595's output as a concrete example of #568's template shape rather than an independently-designed effort — see §9 Q6.

3. Goals

• Ship working skill.md+agents.md pairs (with backing scripts) for the four agents above, piloted against the SEDAC collection since it already has a live, populated custom metadata block (CIESIN) to validate/document against.
• Keep every backing script standalone and dependency-free (stdlib only), independent of any single agent runtime.
• Reuse existing prior art (Dataverse's own validation APIs, the Borealis README Generator, FAIRSCAPE) as a spec/reference rather than duplicating verified work from scratch.

4. Non-Goals

• Modifying Dataverse's core Java codebase — this is external tooling (scripts + skills), not a Dataverse feature.
• Reimplementing FAIRSCAPE's 28-criteria AI-readiness scoring engine from scratch — if pursued at all, wrap/call it (see §9 Q3).
• The CAFE-wide metadata block work (NIH keyword-vocabulary dropdown, required/optional/hidden field audit, codebook/data-dictionary step) from the original CAFE requirements doc — tracked separately; TG: Metadata Task Group #400 (CIESIN) is the only piece confirmed shipped so far, and this effort's Phase 1/2 pilots don't block on the rest.
• Full "Actions" automation (create sub-collection/dataset, upload files) — not yet built for any agent; see §10.

5. Requirements (from issue, restated)

Requirement	Source	Notes
Packaging agent: recommend file layout for NESE tape/disk deposit	#595	Needs a decision on which storage backend(s) CAFE actually targets — not yet built
Compliance agent: verify HDV/CAFE requirements (metadata, docs, file count, packaging)	#595	Phase 1 PoC built (scripts/cafe-deposit-compliance/), covers generic-HDV via validateDatasetJson; CAFE-specific checks pending Phase 0 metadata-status confirmation
Assistant agent: deposit directly via AI workflow, bypassing the UI	#595	Not started; requires the "Actions" (create/upload) capability no agent has yet
README creator agent: draft README from local dir, Dataverse draft, and/or publications	#595	Phase 2 PoC built — see §7
Good/Okay/Poor examples per use case	#595	Not yet authored for any agent
Handle edge cases	#595 (Challenges)	Not yet scoped concretely

6. Proposed Approach

Phased, in the order that minimizes blocking dependencies (compliance and README-generation only need data that already exists; packaging and the full assistant need decisions not yet made):

1. Phase 0 — confirm status of the remaining CAFE-wide metadata work and settle the deliverable-format question (this doc assumes the SKILL.md+AGENTS.md+scripts pattern from §2).
2. Phase 1 — compliance agent. Built as a standalone CLI, not yet wrapped as a skill.
3. Phase 2 — README creator agent. Built two ways: a click-through External Tool fork for UI depositors, and a Claude Code skill for agent-based ones, sharing the same field-mapping spec rather than one depending on the other at runtime.
4. Phase 3 — assistant agent. Largely orchestration over Phase 1/2's existing capability once "Actions" exists.
5. Phase 4 — packaging agent. Blocked on a storage-backend decision.

7. What's Been Built So Far

Phase 1 — scripts/cafe-deposit-compliance/ (uncommitted): dataverse_compliance_check.py, a dependency-free Python CLI validating a dataset (local draft JSON or an already-deposited dataset by PID) against a collection's schema via datasetSchema/validateDatasetJson/curationStatus. Tested offline only (mocked network layer).

Phase 2a — ~/CAFE/README-generator-prototype, branch cafe-hdv-adaptation (committed there, not deployed): a fork of Scholars Portal's open-source Borealis README Generator (a Dataverse External Tool web app), rebranded for Harvard Dataverse, publisher read dynamically instead of hardcoded, plus a new CIESIN Geospatial Metadata section. No LICENSE file upstream — see §9 Q8.

Phase 2b — .claude/skills/cafe-readme-generator/ (committed): a Claude Code skill (SKILL.md + tool-agnostic AGENTS.md) with four stdlib-only Python scripts:

• fetch_dataverse_metadata.py — ports the fork's verified field-extraction logic (including the CIESIN block's single-valued-compound-field shape).
• scan_local_files.py — reads a local directory before upload (the one input source neither the fork nor URGE support), extracts CSV/TSV headers, and flags FAIR-adjacent naming/format issues (unsafe characters, Windows-reserved names, proprietary formats with a suggested alternative, empty files, case-insensitive collisions).
• parse_prior_readme.py — carries forward free-text prose from an existing README (URGE-inspired; URGE is closed-source, so this is an independent implementation).
• render_readme.py — assembles the above, plus agent-authored prose, into the final README; supports --anonymize for double-blind review (also URGE-inspired).

All tested with synthetic/mocked data; none tested against a live Dataverse instance.

8. Architecture / Integration Points

• Dataverse REST APIs used: GET /api/dataverses/{id}/datasetSchema, POST /api/dataverses/{id}/validateDatasetJson, GET/PUT /api/datasets/{id}/curationStatus, GET /api/datasets/:persistentId, and (for Phase 2a) the External Tools framework (POST /api/v1/admin/externalTools, dataset-level configure tool).
• CIESIN metadata block (customCIESIN, per TG: Metadata Task Group #400): FGDC-derived geospatial fields, all single-valued — the recurring gotcha across every script that touches it is that non-multiple compound fields return a single JSON object, not an array, unlike author/contributor.
• No shared runtime dependency between the External Tool fork and the skill — deliberate, so the skill doesn't require the fork to be deployed.

9. Open Questions Summary

1. Do we have a real Harvard Dataverse API token + test/SEDAC dataset to live-test Phase 1/2? Everything built so far is mocked or synthetic.
2. Should "Actions" (create dataset, upload files) be built, and under which agent? Nothing currently deposits anything.
3. Is FAIRSCAPE integration wanted for "Scoring," or out of scope for CAFE Y4?
4. What's the status of the remaining CAFE-wide metadata work (keyword vocab, field audit, codebook step) beyond TG: Metadata Task Group #400?
5. Where would the README-generator fork be deployed, and does registering a Dataverse External Tool need IT/security review at Harvard?
6. Should CAFE Y4: AI-Informed Support for CAFE Dataset Deposit #595 explicitly coordinate with Investigate feasibility of developing agents.md and skill.md Dataverse workflow templates for researchers #568 on a shared template shape, or stay separate?
7. Which storage backend(s) does the packaging agent actually need to target (S3, Globus, NESE tape/disk)? Blocks Phase 4 entirely.
8. Does the Borealis repo's missing LICENSE block forking/redistributing it beyond a private PoC?
9. Should Phase 1's CLI also get a SKILL.md/AGENTS.md wrapper, for consistency with Phase 2?
10. Has anyone contacted Scholars Portal/Borealis or the FAIRSCAPE/Bridge2AI team about collaborating before duplicating their work further?

10. Estimates / Remaining Work

Item	Estimate	Blocked on
Phase 1: live-test + commit	0.5–1 day	Q1
Phase 1: wrap as skill	0.5 day	—
Phase 1: CAFE-specific checks (keyword vocab, codebook)	unscoped	Q4
Phase 2: live-test scripts	few hours	Q1
Phase 2: deploy fork + register External Tool	0.5–1 day engineering, unpredictable on top	Q5
Phase 2: "Actions" (create/upload)	1–2 days, narrow scope	Q2
Phase 2: FAIRSCAPE integration	days–weeks, open-ended	Q3
Phase 3: assistant agent, first version	1–2 days	Q2 (shares Actions gap)
Phase 4: packaging agent	not estimable	Q7
Good/Okay/Poor rubric authoring	0.5–1 day per agent	needs curation-team input, not just engineering

11. Out of Scope / Future Work

• FAIRSCAPE CLI wrapping/integration (Q3).
• Full create-dataset-and-upload automation ("Actions") for any agent (Q2).
• Packaging agent implementation pending storage-backend decision (Q7).
• Production deployment of the README-generator fork (Q5, Q8).
• Formal code review of either script set — both are self-tested only so far.