Creating A Mission
Missions and Tasks
Learn what Missions and Tasks are, how they relate, and how to create a Mission end-to-end.
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
| Role | Who executes | Responsibilities | Examples |
|---|---|---|---|
| Mission Owner | Human | Defines scope/success, prioritizes, approves, receives reports | Data Platform Lead, Analytics Manager |
| Task Owner | Human or Bot | Executes the step, updates status, attaches artifacts | Engineer, FieldMappingAgent, DbtBuildingAgent |
| Stakeholder | Human | Consumes updates, reviews outputs, gives sign-off | Product Owner, Data Steward |
Common use-cases
- 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.
Mission definition
Mission definition
- 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
Genesis Uses These Allowed Source Tables
Genesis Uses These Allowed Source Tables
-
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
Genesis Targets These Tables
Genesis Targets These Tables
-
CLAIM_SUMMARY -
PROVIDER_SUMMARY -
PATIENT_SUMMARY
Genesis Follows The Suggested The Success Criteria
Genesis Follows The Suggested The Success Criteria
- 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
Task blueprint (with dependencies)
Task blueprint (with dependencies)
- Initialize tooling and agents — run
FieldMappingAgent (init)andDbtBuildingAgent (init) - Inventory source fields — inspect
CLAIMS,CLAIM_DETAILS,PATIENTS,PROVIDERS(types, samples) - Define
CLAIM_SUMMARYmapping 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 - Define
PROVIDER_SUMMARYmapping spec — aggregations: TOTAL_CLAIMS, UNIQUE_PATIENTS, TOTAL_CHARGES, TOTAL_PAID, DENIAL_RATE, REPORT_YEAR, REPORT_MONTH; include joins + brief SQL. Depends on: 2 - Define
PATIENT_SUMMARYmapping spec — join CLAIMS and PATIENTS onPATIENT_ID; derivations: PATIENT_FULL_NAME, PATIENT_AGE, AGE_GROUP, REPORT_YEAR/MONTH, totals; include brief SQL. Depends on: 2 - Review and approve mapping specs — Depends on: 3, 4, 5
- Implement dbt models (SQLite) — use
materialized=“table”via tooling; avoid inline config blocks; usesubstr()instead ofsubstring(). Depends on: 6 - Add data quality checks — non-null keys; type conformity; referential integrity (e.g.,
PROVIDER_IDexists inPROVIDERS). Depends on: 7 - Validate models via validation connection — use
sqlite_master,PRAGMA table_info, sample queries; attach results/logs. Depends on: 8 - Historical backfill and verification — run backfill; record row counts and variances. Depends on: 9
- Schedule refresh and alerts — Depends on: 10
- Attach artifacts and handoff notes — mapping specs, dbt links, DQ queries, run logs. Depends on: 11