Overview
The config project is a separate git repository that holds everything client-specific about a billing implementation. The Billing Worker reads from it at runtime — when a workflow runs, the worker loads the YAML and imports the activity scripts from the config project.
What lives in the config project
- Workflow definitions — YAML files in
workflows/that define the billing processes for this client. - Project-specific activities — TypeScript files in
activities/that implement client-specific logic (coverage selection, custom saves, transformation rules). - Validation rules — manifest YAML and TypeScript scripts in
validation-rules/. - Triggers — subscription and schedule trigger definitions in
triggers/. - Auto-generated type declarations — in
manifests/types/, synced from the product (do not edit).
What does not live in the config project
Built-in activities (like fetch-context, build-draft-claim, parse-x12) ship with the Billing Worker Docker image. They are referenced in workflow YAML but their code is not in the config project.
How the worker uses it
The worker mounts the config project as a Docker volume at /data/repo. On each activity execution, it resolves the script path relative to the current branch's directory and dynamically imports the TypeScript file.
For branch-based execution, see Branch-per-Client Model. For how code changes take effect without a worker restart, see Dynamic Reload.
Example structure
my-config-project/
├── workflows/
│ ├── prebill.yaml
│ ├── claim-submission.yaml
│ └── link-claim-response.yaml
├── activities/
│ ├── shared/
│ │ └── fhir-helpers.ts
│ ├── prebill/
│ │ ├── select-coverage.ts
│ │ ├── resolve-charge-items.ts
│ │ └── save.ts
│ └── claim-submission/
│ └── transmit.ts
├── validation-rules/
│ ├── manifest.yaml
│ └── require-patient-dob.ts
├── triggers/
│ └── encounter-finished/
│ ├── definition.yaml
│ └── input-mapping.ts
└── manifests/
└── types/
├── built-in-activities.ts
└── fhir/
└── _types.ts