Project Atlas AetherDev project hub
Atlas project production

Integr8r

Provide a shared PowerShell framework for district integrations, so each vendor flow follows a consistent pattern for config loading, data transforms, and reporting. Operators select a vendor module, load its config files, and run the associated PowerShell scripts. Scripts extract data (often via SQL or CSV), apply per-vendor transformations, and call vendor APIs or generate output files. Report templates in Reports/TEMPLATE are used to build HTML email outputs when workflows include notification steps.

Type
Component
Lifecycle
Active
Last touched
2025-12-11
Visibility
Public

Purpose

Provide a shared PowerShell framework for district integrations, so each vendor flow follows a consistent pattern for config loading, data transforms, and reporting.

Current state

Last touched: 2025-12-11. Functionality and completeness: Modules exist; centralized documentation is limited.

Next step

Add baseline automated tests to cover critical flows; Add CI pipeline for build/test/lint; Document deployment/runtime environment (or add Dockerfile); Document interfaces (CLI flags, API endpoints, file formats); Add structured logging and basic health checks.

Interfaces

Inputs
  • Config .ps1 files, SQL queries, CSVs, vendor API credentials
  • CSV files
Outputs
  • CSV exports, email reports, vendor sync actions
  • Report emails
  • Directory/API updates

Reality to Action trace

Reality Ingestion

Contributes in this stage.

Canonical Storage

Contributes in this stage.

Automation Engines

Not in scope.

Human Interfaces

Contributes in this stage.

Operational Adoption

Contributes in this stage.

Core workflow

TBD. Document the 5-10 steps that define the core workflow.

Artifacts

  • Module-specific CSV schemas and API payloads

Operational notes

Constraints and scars

  • Large surface area and many dependencies; module maintenance requires vendor-specific knowledge and consistent config hygiene.

Reliability posture

Failure modes and safe behavior: Varies per module; errors surfaced in logs or report emails. Idempotency / retries / batching behavior: Varies per module; no centralized retry system.

Observability

  • Logs: Script output and report artifacts; module-specific logging
  • Metrics/health checks: None documented
  • Logs: Script output and report artifacts; logging varies by module.

Security and privacy

Config and report data can include PII and credentials; keep config files local and restrict access to report outputs.

Dependencies

Upstream
  • Multiple vendor systems (Aeries, Google, and others referenced by module folders)

Ownership

Owners

Josh Barton

Users

Josh Barton (owner)

Integr8r

Architecture & Major Components

  • High-level diagram (text):

    • Config (.ps1) -> vendor module scripts -> data transforms -> vendor API/files -> reports

  • Entry points: Integr8r/Integr8r.ps1 and per-vendor scripts in module folders

  • Top-level folders: Config, Modules, Reports, Templates, plus vendor-specific module directories

  • Key abstractions: Config loader (PSConfigModule), vendor modules, report template system

Setup / Build / Run

  • Build system(s): None (PowerShell scripts).
  • Configure module settings under Config/ and run module scripts from a PowerShell host.