atdata 0.2.3b1__tar.gz → 0.3.1b1__tar.gz

atdata-0.3.1b1/.claude/commands/adr.md

@@ -0,0 +1,42 @@
+---
+allowed-tools: Bash(git status:*), Bash(git log:*), Bash(chainlink tree:*), Bash(chainlink comment:*), Bash(chainlink subissue:*), Bash(chainlink create:*), Bash(chainlink session:*), Bash(chainlink --help), Bash(chainlink close:*), Bash(uv run pytest:*), Bash(uv run ruff:*)
+description: Perform an adversarial review
+---
+
+## Context
+
+- Current issue tree: !`chainlink tree`
+- Current test outputs: !`uv run pytest -v`
+- Recent commits: !`git log --oneline -10`
+- Chainlink help: !`chainlink --help`
+
+## Your task
+
+1. Develop summary assessment of test suite
+    - Look through all of the unit tests currently in the project, and create a plan of how well these tests are implemented to test the functionality at the core of the project, how well these tests actually fully cover desired behavior and edge cases, whether the tests are formally correct, and whether there is any redundancy in the tests or documentation for them
+    - Develop a plan for how to address these concerns point by point
+2. Develop summary assessment of codebase
+    - Look through all of the source files currently in the project's main modules, and create a plan of how well-implemented, efficient, and generalizable the current implementation is, as well as whether there is adequate, too sparse, or too verbose documentation
+    - Develop a plan for improvements, tweaks, or refactors that could be applied to the current codebase and its documentation
+3. Create issue and subissues
+    - Create a base issue in chainlink for this adversarial review
+    - Create subissues for each of the plan items addressed in steps 1 and 2.
+4. Address all subissues for this adversarial review
+    - Ordered by priority, address and close each of the subissues identified
+    - Provide thorough documentation of each step you take in the chainlink comments
+
+## Constraints
+
+- **Adversarial**: You are engaging in this task from the perspective of a reviewer that is hyper-critical.
+- **Optimize code contraction**: You are operating as one half of a cyclical dyad, in which the other half is responsible for generating a lot of code, but has a propensity to write too much, and write implementations that are verbose, inefficient, or inaccurate at times. Your job is to be the critical eye, and to identify and implement revisions that make the code concise, efficient, and formally correct.
+- **Consider test correctness**: The tests you are presented with are not necessarily complete for covering the desired functionality. Think through ways in which you could make the test suite more accurate to the task at hand, and also of ways in which you could test the codebase's functionality that are not currently addressed. Be creative and leverage web search in this endeavor to see current best practices for the problem that could aid developing tests.
+- **Preserve documentation for API generation**: This project uses quartodoc to auto-generate API documentation from docstrings. Docstrings are a feature, not bloat. When reviewing documentation verbosity, apply these rules:
+    - **KEEP**: Module-level docstrings, class-level docstrings, `Args:`, `Returns:`, `Raises:`, `Examples:` sections on all public APIs
+    - **KEEP**: Docstrings that explain *why* something works a certain way, non-obvious behavior, or protocol/interface contracts
+    - **KEEP**: `Examples:` sections — these render as live code samples in the docs site
+    - **TRIM**: Docstrings that *only* restate the function signature with no added value (e.g. "`name: The name`" when the type hint already says `name: str`)
+    - **TRIM**: Multi-paragraph explanations on private/internal helpers where a one-liner suffices
+    - **NEVER REMOVE**: Docstrings from public API methods, protocol definitions, or decorated classes
+    - When in doubt, leave the docstring. A slightly verbose docstring that helps a user is better than a missing one that forces them to read source.
+- **Batch mechanical fixes**: Group similar changes (e.g. all weak assertion fixes) into a single commit rather than one subissue per file. Reserve individual subissues for changes that require design thought.
+- **Close low-value issues**: If a finding would add complexity, risk regressions, or save fewer than 10 lines, close it as "not worth the churn" with a comment explaining why.

atdata-0.3.1b1/.claude/commands/changelog.md

@@ -0,0 +1,61 @@
+---
+allowed-tools: Bash(git log:*), Bash(git tag:*), Bash(git diff:*), Bash(chainlink *)
+description: Generate a clean CHANGELOG entry from recent work
+---
+
+## Context
+
+- Current version: !`grep '^version' pyproject.toml`
+- Recent tags: !`git tag --sort=-creatordate | head -5`
+- CHANGELOG head: !`head -20 CHANGELOG.md`
+- Recent chainlink issues: !`chainlink list`
+
+## Your task
+
+Generate a properly structured CHANGELOG entry for the current release, following [Keep a Changelog](https://keepachangelog.com/en/1.0.0/) format.
+
+### 1. Gather changes
+
+Identify all changes since the last release by examining:
+- `git log --oneline <last-release-tag-or-branch>..HEAD` for commit messages
+- `chainlink list` for closed issues and their descriptions
+- `git diff --stat <last-release-tag-or-branch>..HEAD` for files changed
+
+### 2. Categorize changes
+
+Sort changes into Keep a Changelog sections:
+
+- **Added**: New features, new files, new public APIs, new test suites
+- **Changed**: Modifications to existing behavior, refactors, dependency updates, CI changes
+- **Fixed**: Bug fixes, lint fixes, CI fixes
+- **Deprecated**: Newly deprecated APIs (with migration path)
+- **Removed**: Removed features, deleted files, removed APIs
+
+### 3. Write the entry
+
+Follow these formatting rules:
+- Each item should be a concise, user-facing description — not a chainlink issue title
+- Group related changes under bold sub-headers (e.g. **`LocalDiskStore`**: description)
+- Use nested bullets for sub-items that belong to a feature group
+- Omit internal-only changes (individual subissue closes, review assessments, investigation tickets)
+- Include GitHub issue references where relevant (e.g. `(GH#42)`)
+- Do NOT include chainlink issue numbers — these are internal tracking
+
+### 4. Update CHANGELOG.md
+
+- Insert the new version section between `## [Unreleased]` and the previous release
+- Leave `## [Unreleased]` empty at the top
+- Do not modify any existing release sections below
+
+### 5. Verify
+
+- Confirm the CHANGELOG renders as valid markdown
+- Confirm no chainlink auto-appended entries leaked into existing release sections
+
+## Constraints
+
+- Follow Keep a Changelog format strictly
+- Write for the library's users, not for internal tracking
+- Consolidate — 5 well-written bullets are better than 30 issue titles
+- Preserve existing release sections exactly as they are
+- If chainlink has appended noise to existing sections, clean it up

atdata-0.3.1b1/.claude/commands/feature.md

@@ -0,0 +1,43 @@
+---
+allowed-tools: Bash(git *), Bash(chainlink *)
+description: Create a feature branch from a human-readable description
+---
+
+## Context
+
+- Current branch: !`git branch --show-current`
+- Recent release branches: !`git branch --list 'release/*' | tail -5`
+- Existing feature branches: !`git branch --list 'feature/*' | tail -10`
+- Working tree status: !`git status --short`
+- Remotes: !`git remote -v`
+
+## Your task
+
+The user will provide a human-readable description of the feature (e.g. "add batch retry logic"). Create a feature branch following the project's naming convention.
+
+### 1. Derive the branch name
+
+- Slugify the description: lowercase, strip non-alphanumeric characters (except hyphens), replace spaces with hyphens, collapse consecutive hyphens.
+- The branch name is `feature/<slug>` (e.g. `feature/add-batch-retry-logic`).
+- If the slug is empty or the branch already exists, ask the user for a different name.
+
+### 2. Validate preconditions
+
+- Confirm there are no uncommitted changes (other than `.chainlink/issues.db`). If there are, warn the user and ask whether to stash or abort.
+- Identify the base branch. Default to the current branch. If the user provides a `--from <ref>` argument, use that instead.
+
+### 3. Create the branch
+
+- `git checkout -b feature/<slug>` (from the resolved base)
+- Print the created branch name so the user can confirm.
+
+### 4. Track in chainlink
+
+- Create a chainlink issue for the feature work with the user's original description as the title.
+- Set priority to `medium` (unless the user specifies otherwise).
+
+## Constraints
+
+- Never force-push or delete branches.
+- Do not push the branch to a remote — the user will do that when ready.
+- Keep the slug concise. If the description is very long, truncate to the first 6-8 meaningful words.

atdata-0.3.1b1/.claude/commands/release.md

@@ -0,0 +1,63 @@
+---
+allowed-tools: Bash(git *), Bash(gh *), Bash(uv lock*), Bash(uv run ruff*), Bash(uv run pytest*), Bash(chainlink *), Bash(uv run ruff format*)
+description: Prepare and submit a beta release
+---
+
+## Context
+
+- Current branch: !`git branch --show-current`
+- Recent commits: !`git log --oneline -15`
+- All branches: !`git branch --list 'release/*' | tail -5`
+- Current version: !`grep '^version' pyproject.toml`
+- Remotes: !`git remote -v`
+
+## Your task
+
+The user will provide a version string (e.g. `v0.3.0b2`). Perform the full release flow:
+
+### 1. Validate preconditions
+- Confirm all tests pass: `uv run pytest tests/ -x -q`
+- Confirm lint is clean: `uv run ruff check src/ tests/`
+- Confirm formatting is clean: `uv run ruff format --check src/ tests/` (fix with `uv run ruff format src/ tests/` if needed)
+- Confirm no uncommitted changes (other than `.chainlink/issues.db`)
+- Identify the previous release branch to branch from (e.g. `release/v0.3.0b1`)
+- Identify the feature branch to merge (current branch or ask user)
+
+### 2. Create release branch
+- Stash any uncommitted changes
+- `git checkout <previous-release-branch>`
+- `git checkout -b release/<version>`
+- `git merge <feature-branch> --no-ff --no-edit`
+- `git stash pop` (if anything was stashed)
+
+### 3. Prepare release
+- Bump version in `pyproject.toml`
+- Run `uv lock` to update the lockfile
+- Run `/changelog` skill to generate a clean CHANGELOG entry (or generate one manually following Keep a Changelog format with Added/Changed/Fixed sections)
+- Run `uv run ruff check src/ tests/` and fix any lint errors
+- Run `uv run ruff format --check src/ tests/` and fix any format errors (run `uv run ruff format src/ tests/` to auto-fix)
+- Run `uv run pytest tests/ -x -q` to confirm tests pass
+
+### 4. Commit and push
+- `git add pyproject.toml uv.lock CHANGELOG.md .chainlink/issues.db`
+- `git commit -m "release: prepare <version>"`
+- `git push -u origin release/<version>`
+
+### 5. Create PR
+- Create PR to `upstream/main` using `gh pr create`:
+  - `--repo forecast-bio/atdata`
+  - `--base main`
+  - `--head release/<version>`
+  - Title: `release: <version>`
+  - Body: summary of changes from CHANGELOG, test plan with pass counts
+
+### 6. Track in chainlink
+- Create a chainlink issue for the release, close when PR is submitted
+
+## Constraints
+
+- Always use `--no-ff` for merges to preserve branch topology
+- Always run `uv lock` after version bumps — stale lockfiles break CI
+- Always run both `ruff check` and `ruff format --check` before committing — either will fail CI
+- Never force-push to release branches
+- The CHANGELOG should follow Keep a Changelog format with proper Added/Changed/Fixed sections, not a flat list of chainlink issues

{atdata-0.2.3b1 → atdata-0.3.1b1}/.github/workflows/uv-test.yml

@@ -4,13 +4,11 @@ on:
   push:
     branches:
       - main
-      - release/*
   pull_request:
-    branches:
-      - main
 
 permissions:
   contents: read
+  actions: read
 
 concurrency:
   group: ${{ github.workflow }}-${{ github.ref }}
@@ -77,3 +75,60 @@ jobs:
         with:
           fail_ci_if_error: false
           token: ${{ secrets.CODECOV_TOKEN }}
+
+  benchmark:
+    name: Benchmarks
+    runs-on: ubuntu-latest
+    needs: [lint]
+    permissions:
+      contents: write
+      actions: write
+    steps:
+      - uses: actions/checkout@v5
+
+      - name: Set up Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: "3.14"
+
+      - name: Install uv
+        uses: astral-sh/setup-uv@v6
+        with:
+          enable-cache: true
+
+      - name: Install just
+        uses: extractions/setup-just@v2
+
+      - name: Install the project
+        run: uv sync --locked --all-extras --dev
+
+      - name: Start Redis
+        uses: supercharge/redis-github-action@1.8.1
+        with:
+          redis-version: 7
+
+      - name: Run benchmarks
+        run: just bench
+
+      - name: Copy report to docs
+        run: |
+          mkdir -p docs/benchmarks
+          cp .bench/report.html docs/benchmarks/index.html
+
+      - name: Commit updated benchmark docs
+        if: github.event_name == 'push'
+        run: |
+          git config user.name "github-actions[bot]"
+          git config user.email "github-actions[bot]@users.noreply.github.com"
+          git add docs/benchmarks/index.html
+          git diff --cached --quiet || git commit -m "docs: update benchmark report [skip ci]"
+          git push
+
+      - name: Upload benchmark report
+        uses: actions/upload-artifact@v4
+        if: always()
+        with:
+          name: benchmark-report
+          path: |
+            .bench/report.html
+            .bench/*.json

{atdata-0.2.3b1 → atdata-0.3.1b1}/.gitignore

@@ -52,6 +52,9 @@ MANIFEST
 pip-log.txt
 pip-delete-this-directory.txt
 
+# Benchmark results
+.bench/
+
 # Unit test / coverage reports
 htmlcov/
 .tox/

{atdata-0.2.3b1/.planning/setup → atdata-0.3.1b1/.planning/phases/01-atproto-foundation}/decisions/04_schema_evolution.md

@@ -9,7 +9,7 @@
 
 For this, let's take the following approach:
 
-1. Let's make the `rkey` for the `ac.foundation.dataset.sampleSchema` records be of type `any`.
+1. Let's make the `rkey` for the `ac.foundation.dataset.schema` records be of type `any`.
 2. Then, we can have our own standard for the `rkey` being of the format `{NSID}@{semver}`, where `{NSID}` gives an NSID for the permanent identifier of this sample schema type.
     * This allows us to bookkeep on the version updates
     * We can make a `ac.foundation.dataset.getLatestSchema` `query` Lexicon that will provide the record for the latest version of a given schema, as well

{atdata-0.2.3b1/.planning/setup → atdata-0.3.1b1/.planning/phases/01-atproto-foundation}/decisions/05_lexicon_namespace.md

@@ -16,7 +16,7 @@ ac.foundation.dataset.*
 The choices we have then are
 
 ```
-ac.foundation.dataset.sampleSchema
+ac.foundation.dataset.schema
 ac.foundation.dataset.record
 ac.foundation.dataset.lens
 ```

{atdata-0.2.3b1/.planning/setup → atdata-0.3.1b1/.planning/phases/01-atproto-foundation}/decisions/assessment.md

@@ -16,7 +16,7 @@ The finalized design decisions prioritize **flexibility and future-proofing** ov
 2. **Lens Code (#46)**: External repos (GitHub + tangled.org), language metadata, future attestation
 3. **Storage (#47)**: Hybrid (URLs + blobs) from start, AppView proxy for blobs
 4. **Evolution (#48)**: rkey as {NSID}@{semver}, getLatestSchema query, optional migration Lenses
-5. **Namespace (#49)**: `ac.foundation.dataset.*` (sampleSchema, record, lens)
+5. **Namespace (#49)**: `ac.foundation.dataset.*` (schema, record, lens)
 
 ---
 

{atdata-0.2.3b1/.planning/setup → atdata-0.3.1b1/.planning/phases/01-atproto-foundation}/decisions/record_lexicon_assessment.md

@@ -17,7 +17,7 @@ Comprehensive assessment of `ac.foundation.dataset.record` Lexicon design agains
 The record Lexicon provides a solid foundation for dataset indexing with hybrid storage support. Key strengths include clean union-based storage design and appropriate use of ATProto primitives. However, several issues need addressing:
 
 - ⚠️ **Critical**: schemaRef should use format validation
-- ⚠️ **High**: Metadata structure inconsistency with sampleSchema pattern
+- ⚠️ **High**: Metadata structure inconsistency with schema pattern
 - ⚠️ **Medium**: Missing $type discriminators in union variants
 - ✅ **Strength**: Clean storage union design
 - ✅ **Strength**: Appropriate use of tid keys for datasets
@@ -40,8 +40,8 @@ The record Lexicon provides a solid foundation for dataset indexing with hybrid
 - Appropriate for records without natural semantic keys
 - Consistent with ATProto patterns for user-generated content
 
-**Comparison to sampleSchema:**
-- sampleSchema uses `"key": "any"` for versioned rkeys like `{NSID}@{semver}`
+**Comparison to schema:**
+- schema uses `"key": "any"` for versioned rkeys like `{NSID}@{semver}`
 - record uses `"key": "tid"` for chronological dataset entries
 - Both choices are appropriate for their use cases
 
@@ -59,14 +59,14 @@ The record Lexicon provides a solid foundation for dataset indexing with hybrid
 }
 ```
 
-**Problem:** Should use `"format": "at-uri"` like we did for sampleSchema fields.
+**Problem:** Should use `"format": "at-uri"` like we did for schema fields.
 
 **Fix:**
 ```json
 "schemaRef": {
   "type": "string",
   "format": "at-uri",
-  "description": "AT-URI reference to the sampleSchema record",
+  "description": "AT-URI reference to the schema record",
   "maxLength": 500
 }
 ```
@@ -77,7 +77,7 @@ The record Lexicon provides a solid foundation for dataset indexing with hybrid
 
 #### Issue 2.2: License Field Inconsistency ⚠️ **Medium**
 
-sampleSchema metadata:
+schema metadata:
 ```json
 "license": {
   "type": "string",
@@ -97,7 +97,7 @@ record:
 
 **Problem:** Inconsistent maxLength and less detailed guidance.
 
-**Recommendation:** Align with sampleSchema:
+**Recommendation:** Align with schema:
 - maxLength: 200 (to support full URLs)
 - Enhanced description with examples
 - Reference Schema.org license property
@@ -106,7 +106,7 @@ record:
 
 #### Issue 2.3: Tags Field Inconsistency ⚠️ **Medium**
 
-sampleSchema metadata:
+schema metadata:
 ```json
 "tags": {
   "type": "array",
@@ -145,7 +145,7 @@ record:
 "license": {...}
 ```
 
-sampleSchema:
+schema:
 ```json
 "metadata": {
   "type": "object",
@@ -164,10 +164,10 @@ sampleSchema:
 - Pros: More discoverable (top-level fields, indexed/searchable)
 - Pros: Validated by Lexicon
 - Cons: Duplicates structure with metadata blob
-- Cons: Inconsistent with sampleSchema pattern
+- Cons: Inconsistent with schema pattern
 
 **Option B: Unified Metadata Object**
-- Pros: Consistent with sampleSchema
+- Pros: Consistent with schema
 - Pros: Single source of truth
 - Cons: Less discoverable for search
 - Cons: Can't validate blob contents
@@ -298,7 +298,7 @@ storageExternal:
 
 **Arguments for closed: false (current):**
 - Future extensibility (e.g., IPFS-native, Filecoin, Arweave)
-- Consistent with sampleSchema schema union pattern
+- Consistent with schema schema union pattern
 - Graceful degradation for unknown types
 
 **Recommendation:** Keep open but document in description that external/blobs are the canonical types maintained by foundation.ac.
@@ -307,7 +307,7 @@ storageExternal:
 
 ### 8. Missing Fields from Standard Patterns
 
-Comparing to Schema.org Dataset and sampleSchema patterns:
+Comparing to Schema.org Dataset and schema patterns:
 
 **Consider Adding:**
 
@@ -317,7 +317,7 @@ Comparing to Schema.org Dataset and sampleSchema patterns:
 
 2. **Version** - Dataset versioning?
    - Current approach: New record per version (via tid)
-   - Alternative: Add explicit `version` field like sampleSchema
+   - Alternative: Add explicit `version` field like schema
    - **Recommendation:** Document that versioning is via new records, reference via AT-URI with tid
 
 3. **Citation** - How to cite this dataset?
@@ -357,7 +357,7 @@ Comparing to Schema.org Dataset and sampleSchema patterns:
 {
   "$type": "ac.foundation.dataset.record",
   "name": "CIFAR-10 Training Set",
-  "schemaRef": "at://did:plc:abc123/ac.foundation.dataset.sampleSchema/imageclassification@1.0.0",
+  "schemaRef": "at://did:plc:abc123/ac.foundation.dataset.schema/imageclassification@1.0.0",
   "storage": {"type": "external", "urls": ["..."]}
 }
 ```
@@ -400,7 +400,7 @@ Comparing to Schema.org Dataset and sampleSchema patterns:
 ### High Priority (Should Fix)
 
 4. **Align metadata pattern** - Clarify relationship between top-level fields and metadata blob
-5. **Standardize license field** - Match sampleSchema maxLength and description
+5. **Standardize license field** - Match schema maxLength and description
 6. **Standardize tags field** - Use consistent limits or document rationale
 
 ### Medium Priority (Consider)
@@ -419,9 +419,9 @@ Comparing to Schema.org Dataset and sampleSchema patterns:
 
 ## Consistency Matrix
 
-Comparison of patterns between sampleSchema and record Lexicons:
+Comparison of patterns between schema and record Lexicons:
 
-| Pattern | sampleSchema | record | Status |
+| Pattern | schema | record | Status |
 |---------|--------------|--------|--------|
 | AT-URI format | ✅ Uses format | ❌ Missing | **Fix** |
 | License field | 200 chars, detailed | 100 chars, basic | **Align** |
@@ -440,15 +440,15 @@ Comparison of patterns between sampleSchema and record Lexicons:
 1. Add `"format": "at-uri"` to schemaRef field
 2. Change storage union variants to use `$type` discriminator
 3. Verify blob array item type with ATProto specification
-4. Align license field with sampleSchema (maxLength: 200, enhanced description)
-5. Decide on tags limits (recommend matching sampleSchema: 150/30)
+4. Align license field with schema (maxLength: 200, enhanced description)
+5. Decide on tags limits (recommend matching schema: 150/30)
 
 ### Documentation Improvements
 
 6. Add description clarifying metadata blob vs top-level fields relationship
 7. Document that dataset versioning is via new records (tids)
 8. Add note about storage union extensibility
-9. Cross-reference with sampleSchema Lexicon
+9. Cross-reference with schema Lexicon
 
 ### Consider for Phase 2
 
@@ -460,7 +460,7 @@ Comparison of patterns between sampleSchema and record Lexicons:
 
 ## Conclusion
 
-The record Lexicon provides a solid foundation but needs refinement for ATProto compliance and consistency with sampleSchema patterns. The storage union design is excellent, and the use of tids is appropriate. Primary concerns are format validation, union discriminators, and metadata pattern clarity.
+The record Lexicon provides a solid foundation but needs refinement for ATProto compliance and consistency with schema patterns. The storage union design is excellent, and the use of tids is appropriate. Primary concerns are format validation, union discriminators, and metadata pattern clarity.
 
 **Estimated effort to address critical issues:** 2-3 hours
 **Recommended timeline:** Before Phase 1 completion

atdata-0.2.3b1/.planning/setup/decisions/sampleSchema_design_questions.md → atdata-0.3.1b1/.planning/phases/01-atproto-foundation/decisions/schema_design_questions.md

@@ -1,6 +1,6 @@
-# sampleSchema Lexicon Design Questions
+# schema Lexicon Design Questions
 
-This document captures open design questions for the `ac.foundation.dataset.sampleSchema` Lexicon that require user decisions before implementation.
+This document captures open design questions for the `ac.foundation.dataset.schema` Lexicon that require user decisions before implementation.
 
 ## Q1: Key Format Validation
 
@@ -156,7 +156,7 @@ Should we add an explicit default value for `ndarrayShimUri`?
 
 ## Notes
 
-These questions should be resolved before finalizing the sampleSchema Lexicon design. Some can be deferred to Phase 2 implementation based on priority.
+These questions should be resolved before finalizing the schema Lexicon design. Some can be deferred to Phase 2 implementation based on priority.
 
 **Priority:**
 - Q1: High (affects rkey strategy)

{atdata-0.2.3b1/.planning/setup → atdata-0.3.1b1/.planning/phases/01-atproto-foundation}/examples/code/ndarray_roundtrip.py

@@ -41,7 +41,7 @@ def bytes_to_array(b: bytes) -> np.ndarray:
 # Step 2: Load the JSON Schema for ImageSample
 
 # Get path to the schema example
-schema_path = Path(__file__).parent.parent / "sampleSchema_example.json"
+schema_path = Path(__file__).parent.parent / "schema_example.json"
 with open(schema_path) as f:
     schema_record = json.load(f)
 

{atdata-0.2.3b1/.planning/setup → atdata-0.3.1b1/.planning/phases/01-atproto-foundation}/examples/code/validate_ndarray_shim.py

@@ -312,5 +312,5 @@ print("""
    - Shim definition is sound and reusable
    - Works as both inline $def and external $ref
    - Compatible with JSON Schema tooling
-   - Ready for use in ac.foundation.dataset.sampleSchema Lexicon
+   - Ready for use in ac.foundation.dataset.schema Lexicon
 """)

{atdata-0.2.3b1/.planning/setup → atdata-0.3.1b1/.planning/phases/01-atproto-foundation}/examples/dataset_blob_storage.json

@@ -1,7 +1,7 @@
 {
   "$type": "ac.foundation.dataset.record",
   "name": "Small Sample Dataset",
-  "schemaRef": "at://did:plc:def456/ac.foundation.dataset.sampleSchema/textsample@2.1.0",
+  "schemaRef": "at://did:plc:def456/ac.foundation.dataset.schema/textsample@2.1.0",
   "storage": {
     "$type": "ac.foundation.dataset.storageBlobs",
     "blobs": [

{atdata-0.2.3b1/.planning/setup → atdata-0.3.1b1/.planning/phases/01-atproto-foundation}/examples/dataset_external_storage.json

@@ -1,7 +1,7 @@
 {
   "$type": "ac.foundation.dataset.record",
   "name": "CIFAR-10 Training Set",
-  "schemaRef": "at://did:plc:abc123/ac.foundation.dataset.sampleSchema/imageclassification@1.0.0",
+  "schemaRef": "at://did:plc:abc123/ac.foundation.dataset.schema/imageclassification@1.0.0",
   "storage": {
     "$type": "ac.foundation.dataset.storageExternal",
     "urls": [

{atdata-0.2.3b1/.planning/setup → atdata-0.3.1b1/.planning/phases/01-atproto-foundation}/examples/lens_example.json

@@ -1,8 +1,8 @@
 {
   "$type": "ac.foundation.dataset.lens",
   "name": "RGB to Grayscale Conversion",
-  "sourceSchema": "at://did:plc:abc123/ac.foundation.dataset.sampleSchema/rgbimage@1.0.0",
-  "targetSchema": "at://did:plc:abc123/ac.foundation.dataset.sampleSchema/grayscaleimage@1.0.0",
+  "sourceSchema": "at://did:plc:abc123/ac.foundation.dataset.schema/rgbimage@1.0.0",
+  "targetSchema": "at://did:plc:abc123/ac.foundation.dataset.schema/grayscaleimage@1.0.0",
   "description": "Converts RGB images to grayscale using standard luminosity formula",
   "getterCode": {
     "repository": "https://github.com/alice/vision-lenses",

atdata-0.2.3b1/.planning/setup/examples/sampleSchema_example.json → atdata-0.3.1b1/.planning/phases/01-atproto-foundation/examples/schema_example.json

@@ -1,10 +1,10 @@
 {
-  "$type": "ac.foundation.dataset.sampleSchema",
+  "$type": "ac.foundation.dataset.schema",
   "name": "ImageSample",
   "version": "1.0.0",
   "schemaType": "jsonSchema",
   "schema": {
-    "$type": "ac.foundation.dataset.sampleSchema#jsonSchemaFormat",
+    "$type": "ac.foundation.dataset.schema#jsonSchemaFormat",
     "$schema": "http://json-schema.org/draft-07/schema#",
     "title": "ImageSample",
     "type": "object",

{atdata-0.2.3b1/.planning/setup → atdata-0.3.1b1/.planning/phases/01-atproto-foundation}/lexicons/README.md

@@ -6,16 +6,16 @@ This directory contains the ATProto Lexicon JSON definitions for the distributed
 
 ### Core Record Types
 
-1. **[ac.foundation.dataset.sampleSchema](ac.foundation.dataset.sampleSchema.json)**
+1. **[ac.foundation.dataset.schema](ac.foundation.dataset.schema.json)**
    - Defines PackableSample-compatible sample types using JSON Schema
    - Supports versioning via rkey format: `{NSID}@{semver}`
    - Includes NDArray shim for ML/scientific data types
-   - Example: [sampleSchema_example.json](../examples/sampleSchema_example.json)
+   - Example: [schema_example.json](../examples/schema_example.json)
 
 2. **[ac.foundation.dataset.record](ac.foundation.dataset.record.json)**
    - Index records for WebDataset-backed datasets
    - Hybrid storage support (external URLs + PDS blobs)
-   - References sampleSchema for type information
+   - References schema for type information
    - Examples:
      - [External storage](../examples/dataset_external_storage.json)
      - [Blob storage](../examples/dataset_blob_storage.json)
@@ -40,7 +40,7 @@ This directory contains the ATProto Lexicon JSON definitions for the distributed
 All Lexicons use the `ac.foundation.dataset.*` namespace:
 - `ac.foundation` - Organization namespace
 - `dataset` - Domain (distributed datasets)
-- Specific record types: `sampleSchema`, `record`, `lens`
+- Specific record types: `schema`, `record`, `lens`
 
 ### 2. Schema Versioning (rkey Convention)
 
@@ -57,7 +57,7 @@ All Lexicons use the `ac.foundation.dataset.*` namespace:
 - Natural query pattern via `getLatestSchema`
 - Clear semantic versioning enforcement
 
-**Implementation**: The sampleSchema Lexicon uses `"key": "any"` to support this custom format.
+**Implementation**: The schema Lexicon uses `"key": "any"` to support this custom format.
 
 ### 3. JSON Schema with NDArray Shim
 
@@ -151,7 +151,7 @@ schema_uri = publisher.publish_schema(
     version="1.0.0",
     description="RGB image with label"
 )
-# Result: at://did:plc:abc123/ac.foundation.dataset.sampleSchema/imagesample@1.0.0
+# Result: at://did:plc:abc123/ac.foundation.dataset.schema/imagesample@1.0.0
 ```
 
 ### Publishing a Dataset
@@ -226,7 +226,7 @@ See [06_lexicon_validation.md](../decisions/06_lexicon_validation.md) for valida
 
 ```bash
 # Validate Lexicon JSON (requires ATProto tooling)
-atproto-lexicon validate ac.foundation.dataset.sampleSchema.json
+atproto-lexicon validate ac.foundation.dataset.schema.json
 
 # Validate example records
 python scripts/validate_examples.py