Purpose
Provide a reusable district CLI for InformedK12 response export and data-source upload, with active production support for Short-Term Independent Study workflows.
Current state
The strongest current production evidence is the nightly Aeries demographic upload into the `elementary-stu-demo` and `secondary-stu-demo` InformedK12 data sources used by the district's Short-Term Independent Study forms. Broader CLI capabilities remain available for other workflow-specific exports or uploads, but the Short-Term IS path is the clearly documented production use.
Next step
Document the production data-source identifiers, owning forms or campaigns, and operator ownership for the Short-Term IS workflow, using placeholders where source-system identifiers are still pending review.
Interfaces
Inputs- campaign IDs
- data-source IDs
- API token
- CSV uploads
- district SQL outputs
Outputs- JSONL and CSV exports
- InformedK12 data-source updates
Reality to Action trace
Reality IngestionContributes in this stage.
Canonical StorageNot in scope.
Automation EnginesNot in scope.
Human InterfacesContributes in this stage.
Operational AdoptionContributes in this stage.
Core workflow
TBD. Document the 5-10 steps that define the core workflow.
Data integrity and contracts
Source of truth rules
- InformedK12 is canonical for form workflow state and stored responses.
- District SQL or sheet sources remain canonical for uploaded source data where the CLI pushes structured datasets into InformedK12.
Safe handling
- Keep API tokens and upload files out of public docs.
- Treat pilot workflow data as restricted until access rules are documented.
- Document per-workflow approval and rollback expectations before broad rollout.
Operational notes
Reliability posture
The CLI is production-capable and suited to live sync work, but district business workflows on top of it still need explicit promotion criteria and runbooks.
Observability
- stdout tracing
- request status summaries
- CSV header and row-count checks
Security and privacy
API tokens, uploaded CSVs, and workflow data remain internal and may contain restricted student or staff information depending on the form.
Dependencies
Upstream- InformedK12 API
- district SQL source queries
- workflow-specific approvals
Downstream- district pilot workflows
- structured form implementations
- transfer-related sync work where applicable
Ownership
OwnersTechnology Services, Josh Barton
UsersTechnology Services, workflow owners
Operational Notes
- The CLI and shell runner remain the connector layer, but the district now has a clearly documented production workflow on top of them.
- Current evidence is strongest for the Short-Term Independent Study data-source upload pattern:
informedk12-sync.sh builds Aeries demographics extracts, validates row counts and headers, diffs against prior runs, and uploads the elementary-stu-demo and secondary-stu-demo data sources nightly. - Workflow-specific use cases remain separate where warranted. District Transfer Tracking has its own transfer-related pipeline, while broader InformedK12 export or upload use cases still need their own validation.
Known District Use Cases
- Production Short-Term Independent Study demographic upload into the
elementary-stu-demo and secondary-stu-demo InformedK12 data sources. - Response export as JSONL or CSV for workflow analysis and downstream validation.
- Additional workflow scaffolding for digital form processes where production promotion is still pending review.
Registry Alignment
- Mapped registry scope:
INT-053, with former INT-052 now treated as component context within the same production integration. - Registry clarified: the active production workflow is the Short-Term Independent Study demographic upload path, while the broader CLI remains the reusable connector layer behind it.
- Validation gaps: production data-source identifiers, form or campaign identifiers
[placeholder pending review], live configs and subcommands, and workflow-level owners remain incompletely documented.
