Project Atlas AetherDev project hub
Atlas project concept

Aether Integrator Platform

Centralize integration workflows in a single web app so connectors share authentication, scheduling, and audit controls instead of bespoke scripts. It ingests Aeries API (staff/students), Aeries SQL (students, staff, courses, sections), OCDE HR SQL, Snipe-IT assets, Apex Learning API, Google Admin SDK and produces admin UI views, local database tables, and planned vendor sync actions/audit logs.

Playbook available

Operational guidance is available for this system.

Open playbook
Type
System
Lifecycle
Prototyping
Last touched
2025-09-06
Visibility
Public
Why it's showcased

Represents the platform strategy for consolidating integrations with shared auth, scheduling, and audit controls.

Purpose

Centralize integration workflows in a single web app so connectors share authentication, scheduling, and audit controls instead of bespoke scripts.

Current state

Last touched: 2025-09-06. Functionality and completeness: Scaffolded Laravel app with setup notes; core UI and integration models exist, but connector behavior and job orchestration need definition.

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
  • Aeries API (staff/students), Aeries SQL (students, staff, courses, sections), OCDE HR SQL, Snipe-IT assets, Apex Learning API, Google Admin SDK
  • Aeries API/SQL data
  • OCDE HR SQL data
  • Snipe-IT inventory DB
  • operator triggers
Outputs
  • admin UI views, local database tables, and planned vendor sync actions/audit logs
  • job statuses

Reality to Action trace

Reality Ingestion

Not in scope.

Canonical Storage

Contributes in this stage.

Automation Engines

Contributes in this stage.

Human Interfaces

Contributes in this stage.

Operational Adoption

Contributes in this stage.

Core workflow

  1. Configure environment, database connections, and API credentials.
  2. Define connectors and mapping rules for each integration.
  3. Trigger or schedule integration jobs.
  4. Pull source data from SIS/HR/asset systems.
  5. Normalize and persist records in the local database.
  6. Run diff/apply logic to update target vendors.
  7. Record job status, logs, and audit artifacts.
  8. Review results in the admin UI and resolve exceptions.

Data integrity and contracts

Canonical schema definitions

  • Local DB schemas for integrations, connectors, jobs, and sync state.
  • Connector configuration contract (source, mapping, credentials).
  • Audit log and job status schemas.
  • Canonical person/asset models shared across connectors.

Source of truth rules

  • Source systems (Aeries/HR/Snipe-IT) remain canonical.
  • Local DB is a staging layer, not a system of record.
  • Target vendor systems are updated only through approved connectors.
  • Mapping rules define authoritative field transformations.

Data quality checks

  • Connectivity checks for each source before job run.
  • Row-count and delta checks on extracts.
  • Mapping coverage checks for required codes or values.
  • Schema mismatch detection between source and local models.
  • Per-record validation with exception reports.

Safe handling

  • Protect .env secrets and restrict admin access.
  • Use least-privilege service accounts for each connector.
  • Redact sensitive values in logs and error reports.
  • Rotate API keys and DB credentials on schedule.

Downstream integration map

  • Vendor integrations (TitanHST, ASCIP, Snipe-IT, etc.).
  • Admin dashboards and job history.
  • Audit and compliance reporting.

Artifacts

  • Aeries API endpoints for staff and students; SQL Server table schemas consumed by Eloquent models; Snipe-IT assets table
  • High-level architecture diagram
  • Connector interface spec
  • Permission roles matrix
  • First integration case study (TitanHST)

Operational notes

Constraints and scars

  • Initial setup depends on correct DB credentials and PHP extensions; some data sources may require SSH tunneling in dev.
  • Platform scope can balloon without strict boundaries.

Reliability posture

Failure modes and safe behavior: Upstream DB/API failures surface in UI or logs; no automated fallback documented. Idempotency / retries / batching behavior: Job semantics are not documented; connectors should be designed to be idempotent.

Observability

  • Logs: Laravel application logs (storage/logs) and admin views for jobs/logs/mail logs
  • Metrics/health checks: Not implemented beyond Laravel logs and UI pages
  • admin UI pages for jobs/failed jobs/logs/mail logs (present in code)

Security and privacy

Protect .env secrets (DB credentials, API keys) and restrict access to admin endpoints. Integration seed data contains endpoint placeholders and credential fields; keep seed files private and sanitized. If development requires SSH tunnels to internal data sources, keep tunnel configs private and audited.

Dependencies

Upstream
  • Aeries API/SQL, OCDE HR 2.0 SQL, Snipe-IT DB, Apex Learning API, Google Admin SDK
  • Aeries SQL
Downstream
  • Operational dashboards
  • downstream vendor syncs (planned)

Ownership

Owners

Josh Barton

Users

IT, integration owner, future maintainers, Josh Barton (owner)

aether-integr8r

Architecture & Major Components

  • High-level diagram (text):

    • Web UI/API -> job orchestration -> connector logic -> audit/logging -> downstream systems

  • Entry points: public/index.php

  • Top-level folders: app, bootstrap, config, database, resources, routes, storage, tests

  • Key abstractions: Livewire admin modules, integration/automation models, Aeries API wrappers (AERIES-CERT header), SQL-backed models for Aeries/OCDE, Snipe-IT asset model

Setup / Build / Run

  • Build system(s): Composer + npm.
  • Configure .env (multiple DB connections and API tokens), run migrations/seeds, and serve via Laravel or Apache/Nginx (see README).

Related playbooks