Skip to main content
Missions align teams on a clear goal, scope, and success criteria. Tasks are the verifiable steps that achieve that goal.
Human-in-the-loop: Every Mission has a Mission Owner (human). Genesis data agents execute Tasks, escalate questions, surface insights, and report results to the Mission Owner.

​
What are Missions & Tasks?

Mission

A goal-led charter for related data work that defines the desired outcome, scope, success criteria, and ownership.

Task

A specific, testable unit of work within a Mission. Tracks owner, status, history, and attachments.

Dependencies

Order-of-operations between Tasks to ensure prerequisites are met before execution.
Terminology: In the UI you’ll see Mission and Task. In some tooling you may see Project and Todo. These are equivalent (Mission ≈ Project, Task ≈ Todo).

​
Overview

  • Missions coordinate multi-step outcomes with clarity on scope and success criteria.
  • Tasks break work into small, verifiable steps.
  • Dependencies ensure correct order when required.
  • Attach files/links for specs, outputs, and auditability.

​
Roles at a glance

RoleWho executesResponsibilitiesExamples
Mission OwnerHumanDefines scope/success, prioritizes, approves, receives reportsData Platform Lead, Analytics Manager
Task OwnerHuman or BotExecutes the step, updates status, attaches artifactsEngineer, FieldMappingAgent, DbtBuildingAgent
StakeholderHumanConsumes updates, reviews outputs, gives sign-offProduct Owner, Data Steward

​
Common use-cases

  • Data Engineering
  • Data Ops
  • Source onboarding: ingest → stage → model → validate → schedule
  • Field mapping and schema alignment across systems
  • dbt model development/refactoring and documentation
  • Data quality and lineage improvements
  • Backfills and schema evolution

​
How Missions and Tasks work

1

Define the Mission

Go to Missions → New Mission. Provide a concise, outcome-oriented name and a description with scope and success criteria (what “completed” means). Assign a Mission Owner for approvals and final sign-off.
2

Genesis creates tasks

Genesis converts the Mission into small, testable steps with acceptance criteria and assigns them to specialized data agents.
3

Genesis sets dependencies

Dependencies are added so steps run in the correct order.
4

Configure escalation

Define where agents escalate (e.g., Slack channel, email) and who approves decisions.
5

Execute & attach

Data agents execute work, attach artifacts (docs, SQL, logs), and update status/history.
6

Validate outcomes

Outcomes are validated at each step during autonomous execution.
7

Close the Mission

When acceptance criteria are met and all Tasks are done, the Mission Owner verifies that success criteria have been met and closes the Mission.

​
Create your first Mission

Try it out! Select the Field Mapping mission in the Genesis UI below and create your first Mission. Then watch the data agents work autonomously.

Creating the Healthcare Data Pipeline Mission

​
Reference Example To Illustrate What’s Happening: Healthcare Data Pipeline

Everything below highlights what’s happening in the mission you just created.
  • Name: Healthcare Data Pipeline
  • Mission Owner (human): Data Platform Lead
  • Description: Map fields from demo healthcare bronze tables, build dbt models (SQLite), and validate outputs
  • Spec file attached: project.yml
  • Source connection: HCLS_DEMO_1_SOURCES (bronze)
  • Optional docs index for research: informatica_legacy
  • HCLS_DEMO_1_SOURCES.HCLS_DEMO_1_SOURCES.MAIN.CLAIMS
  • HCLS_DEMO_1_SOURCES.HCLS_DEMO_1_SOURCES.MAIN.CLAIM_DETAILS
  • HCLS_DEMO_1_SOURCES.HCLS_DEMO_1_SOURCES.MAIN.PATIENTS
  • HCLS_DEMO_1_SOURCES.HCLS_DEMO_1_SOURCES.MAIN.PROVIDERS
  • CLAIM_SUMMARY
  • PROVIDER_SUMMARY
  • PATIENT_SUMMARY
  • Approved mapping specs (fields, types, transformations, constraints)
  • dbt models materialize successfully (SQLite: materialized=“table”)
  • Data quality checks pass (non-null keys, type conformity, referential integrity)
  • Historical backfill completes with expected row counts
  1. Initialize tooling and agents — run FieldMappingAgent (init) and DbtBuildingAgent (init)
  2. Inventory source fields — inspect CLAIMS, CLAIM_DETAILS, PATIENTS, PROVIDERS (types, samples)
  3. Define CLAIM_SUMMARY mapping spec — columns: CLAIM_ID, CLAIM_DATE, PATIENT_ID, PROVIDER_ID, CLAIM_TYPE, CLAIM_STATUS, PRIMARY_DIAGNOSIS, TOTAL_CHARGE, INSURANCE_PAID, PATIENT_RESPONSIBILITY; include joins + brief SQL snippet. Depends on: 1, 2
  4. Define PROVIDER_SUMMARY mapping spec — aggregations: TOTAL_CLAIMS, UNIQUE_PATIENTS, TOTAL_CHARGES, TOTAL_PAID, DENIAL_RATE, REPORT_YEAR, REPORT_MONTH; include joins + brief SQL. Depends on: 2
  5. Define PATIENT_SUMMARY mapping spec — join CLAIMS and PATIENTS on PATIENT_ID; derivations: PATIENT_FULL_NAME, PATIENT_AGE, AGE_GROUP, REPORT_YEAR/MONTH, totals; include brief SQL. Depends on: 2
  6. Review and approve mapping specs — Depends on: 3, 4, 5
  7. Implement dbt models (SQLite) — use materialized=“table” via tooling; avoid inline config blocks; use substr() instead of substring(). Depends on: 6
  8. Add data quality checks — non-null keys; type conformity; referential integrity (e.g., PROVIDER_ID exists in PROVIDERS). Depends on: 7
  9. Validate models via validation connection — use sqlite_master, PRAGMA table_info, sample queries; attach results/logs. Depends on: 8
  10. Historical backfill and verification — run backfill; record row counts and variances. Depends on: 9
  11. Schedule refresh and alerts — Depends on: 10
  12. Attach artifacts and handoff notes — mapping specs, dbt links, DQ queries, run logs. Depends on: 11
⌘I