Playbooks

TitanHST Integration Connector Playbook

Operational plan for the TitanHST connector as the first Aether Integrator proof-of-concept.

System map

This playbook supports

TitanHST Integration Connector

Prove the Aether Integrator architecture with a connector that matters operationally. It ingests Aeries + HR 2.0 source truth; TitanHST API (details pending) and produces synced TitanHST records; audit logs; job statuses.

Pipeline

Reality Ingestion Automation Engines Operational Adoption

Domains

Vendor Integrations SIS / HR Data Governance

Patterns

Connector Architecture Mapping Layer Diff Apply Audit

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.

Pipeline

Automation Engines Canonical Storage Operational Adoption Human Interfaces

Domains

Vendor Integrations Automation Platform Identity Data Governance

Patterns

Connector Architecture Platform Governance Diff Apply Audit

Purpose

Validate the Aether Integrator architecture with a real, high-value vendor integration. This playbook documents the connector lifecycle, emphasizing mapping contracts, diff-and-apply safety, and auditability.

When to use this playbook

Before implementing or running the TitanHST connector workflow.
When mapping rules or source schemas change.
When validating diff outputs or audit results with stakeholders.

Signals to stop or escalate

TitanHST API schema or auth changes invalidate the mapping contract.
Diff outputs contain unexpected deletes or role changes.
Rate limits or vendor errors block completion of runs.

Current maturity

Status: idea.
Implementation details are TBD pending schema and API discovery.

Audience and access

Primary operators: integration owner and platform maintainer.
Required access: TitanHST API credentials (TBD), Aeries/HR exports, platform admin access.

Data contract (must be defined before implementation)

Source systems: Aeries + HR 2.0 exports.
Target system: TitanHST API (schema TBD).
Mapping rules for IDs, positions, and attributes (TBD).
Diff semantics for creates/updates/deletes.

Patterns in use

Inputs

Canonical staff and role data from Aeries/HR.
Mapping tables for vendor-specific IDs and values.
Connector configuration and credentials.

Outputs

Synced TitanHST records.
Audit logs and run summaries.
Status reports for stakeholders.

Run steps (planned)

Build the mapping contract
- Define fields, normalization rules, and required IDs.
Implement extract + normalize
- Produce clean, canonical records from source data.
Compute diff against TitanHST
- Determine adds, updates, and removals.
Apply changes with audit logging
- Record all actions and outcomes.
Validate results
- Spot-check records and confirm counts.

Validation checklist

Mapping coverage for all required roles and locations.
Diff output reviewed prior to apply (if dry-run supported).
No unexpected deletes or role changes.

Failure modes and recovery

Vendor API schema mismatch
- Mitigation: pause apply and update mapping contract.
Partial runs or rate limits
- Mitigation: retry with backoff and resume support (TBD).
Unmapped IDs
- Mitigation: update mapping tables and re-run.

Security and privacy

PII and potentially sensitive operational data present.
Ensure least-privilege credentials and access logging.
Define retention policy for audit logs (TBD).

Change management

Version the mapping contract and connector config.
Record connector milestones in the decision log.
Update the playbook as implementation stabilizes.

Open items and next decisions

TitanHST API documentation and auth model.
Required fields and ID mapping approach.
Job scheduling and cadence once in production.