01HR · Business workflow

Build an employee-onboarding app around your team's responsibilities.

Coordinate each new starter's work across HR, IT and teammates. Give every task an owner, a due date and a protected completion record.

CanLang builds the app
Records, permissions, workflows and connected screens.
Soda OS runs the factory
AI development, persistent Projects and reviewed changes.

Illustrative application and company rules. CanLang also works independently of Soda OS.

View CanLangBack to app
Onboarding.canExcerpt

Task completion and reassignment

When
 crud Starter by=hr fields=name,employee,start_date,department delete=none
 crud Task by=hr fields=starter,title,responsible,due_date when=not row.done delete=none
 # The teammate responsible for a task records its completion.
 scenario complete(task:Task,note:text?) by=members
  require task.responsible==actor and not task.done
  do set task {done=true,completed_at=now,completion_note=note}
 # HR can hand unfinished work to another teammate.
 scenario reassign(task:Task,responsible:user) by=hr
  require not task.done
  do set task {responsible}

Onboarding · App preview

Onboarding

Sam

Operations · Starts 8 Mar
1 / 3complete
  • Prepare equipmentAlex · 5 Mar · Unfinished
  • Read safety handbookSam · 8 Mar · Completed
  • Welcome sessionTeam lead · 18 Mar · Unfinished

Illustrative application interface · sample records.

02CanLang · Application model

People, records and rules.

Your department decides how the work should run. This example expresses those decisions in CanLang: the records it stores, who can access them, and the rules each action must follow.

Records the CanLang app keeps

Illustrative first-version records and relationships
StarterSam
Start date
8 March
Department
Operations

HR assigns the joining tasks

  1. Task · UnfinishedPrepare equipment
    Assignee
    Alex · IT
    Due date
    5 March
  2. Task · CompletedRead the safety handbook
    Assignee
    Sam
    Completion
    8 March · 09:12
  3. Task · UnfinishedWelcome session
    Assignee
    Team lead
    Due date
    18 March

A Starter connects name, employee account, start date and department. Each Task records its starter, title, responsible teammate, due date, completion time and optional note.

First-version workflow

  1. Unfinished
  2. Completed

People and app access

HR coordinator
Register starters, assign due dates, see the overview and reassign unfinished work.
Alex in IT and the team lead
Read their assigned tasks and the starter information needed for them; complete their own work.
Sam, the new teammate
Read Sam's starter record and tasks assigned to Sam; complete those tasks.

What these permissions mean

Expected behavior · illustrative cases, not executed test results

Allowed
Alex completes the unfinished equipment task assigned to Alex.
Refused
Alex completes Sam’s handbook task.
CanLang · Explicit business rules

What the app protects

The department sets these requirements. The CanLang application expresses the permissions and workflow restrictions.

  1. IT and team lead are story responsibilities, not extra permission roles.

  2. Being the starter does not grant access to everyone's tasks. Unrelated teammates cannot read the records.

  3. HR coordination alone does not allow completing another person's task. Only its current assignee completes unfinished work.

  4. HR can reassign unfinished work; completed identity, owner, due date and completion records remain protected.

These are application permissions and business rules. Soda OS and Forgejo govern the separate development and code-review process in section 04.

See how these records and responsibilities connect
Illustrative workflow · HR
SamNew starter
EquipmentAlex · IT
HandbookSam
WelcomeTeam lead
One starter. Separate responsibilities.

HR assigns and follows the work. Each assignee sees and completes their own unfinished tasks.

Access to Sam's starter record does not expose every task.

Read this app’s CanLang source
03CanLang · Application experience

Use the app. Check the result.

Follow the first-version workflow through its screens, then check that the app allows the right actions and protects the right records.

A walkthrough of the first version

  1. HR assigns Sam's work

    HR follows the overview and may reassign unfinished tasks to another available teammate.

  2. Alex prepares equipment

    Assignment gives Alex access to this task, without opening Sam's other tasks.

  3. Sam completes the handbook task

    Sam completes Sam's task. Alex cannot complete it, and completed details remain protected.

View CanLangBack to app
Onboarding.canExcerpt

Task completion and reassignment

When
 crud Starter by=hr fields=name,employee,start_date,department delete=none
 crud Task by=hr fields=starter,title,responsible,due_date when=not row.done delete=none
 # The teammate responsible for a task records its completion.
 scenario complete(task:Task,note:text?) by=members
  require task.responsible==actor and not task.done
  do set task {done=true,completed_at=now,completion_note=note}
 # HR can hand unfinished work to another teammate.
 scenario reassign(task:Task,responsible:user) by=hr
  require not task.done
  do set task {responsible}

Illustrative first-version application

Onboarding
WorkspacePeople Internal app
People / Onboarding

Sam’s joining plan

Assignments, deadlines and completion

SamNew starter · Operations
Joining tasks1 of 3 complete
Prepare equipmentAlex · IT · Due 5 March
Unfinished
Read the safety handbookSam · Due 8 March
Completed
Welcome sessionTeam lead · Due 18 March
Unfinished
View handbook completion
Completed by
Sam
Completed at
8 March · 09:12
Completion note
Safety handbook read.

Completed task details and ownership are protected.

Manage unfinished assignments
Prepare equipment
Assigned to Alex · IT
Welcome session
Assigned to Team lead

HR can assign or reassign unfinished work. Only the current assignee can complete a task.

Illustrative application interface. The linked CanLang browser demo has the smaller scope described below.

Your department · Acceptance checklist

Does this version do the job?

Use these expected outcomes to accept the CanLang app. Try the relevant roles, including actions that must be refused.

Checks to perform on the illustrative first version; these are not reported test results.

Employee onboarding · First version

Expected outcomes

  1. HR assigns and tracks work; ordinary teammates see their own tasks.

  2. Sam completes Sam's unfinished task; Alex is refused.

  3. After reassignment, only the current assignee completes the work.

  4. Completion protects task identity, owner, due date and recorded details.

  5. Relevant starter access does not expose every onboarding task.

Reference: the sample records behind these checks

HR assigns Sam's work

Starter
Sam
Prepare equipment
Alex · unfinished
Welcome session
Team lead · unfinished

Alex prepares equipment

Task
Prepare equipment
Assignee
Alex in IT
Visibility
Assigned work and relevant starter details

Sam completes the handbook task

Task
Read the safety handbook
Assignee
Sam
Status
Completed · completion recorded

Try a focused CanLang demo

The compact demo covers assignment, restricted completion and locked completed details. Larger source adds starters, due dates, reassignment and notes. The scheduling continuation is a separate version beyond that browser demo.

Try the task example in CanLang
04Soda OS · Software factory

Develop and review the app.

Your department defines the result. Soda OS coordinates authorised coding agents in a persistent Project; Forgejo records the work and applies the review and merge policy.

Start from the business request

“We need one place to coordinate each new starter's tasks. HR should assign work and follow progress. Each teammate should see their tasks and complete only the work assigned to them. Completed details should stay protected.”

Follow the development process

Move through the stages below: accepted direction, dependent work items, CanLang source, independent review and policy-governed integration.

Corrections and human approval apply where required by repository policy. Merging code and deploying the application are separate actions.

The request, work items and review cases are illustrative, not a recording of a completed factory run.

1 / 6 · HR owns the direction

Agree on what good onboarding looks like.

Open New Project and answer “What do you want to build?” Explore ideas turns the request into a direction. HR uses “Review your product direction” to accept the experience or ask for changes.

What carries forward

An accepted product direction. Material questions return to HR instead of becoming hidden assumptions.

Example accepted direction

Example accepted direction

Onboarding tasks, with clear ownership

  1. HR assigns and follows work

    Create tasks, choose a responsible teammate and see the full list.

  2. Teammates see their own tasks

    Only the assigned person can complete a task.

  3. Completed tasks keep their history

    Lock the title and owner after completion. Keep deletion unavailable.

Illustrative workflow artifact from the selected department journey.

2 / 6 · Soda coordinates the work

Turn the direction into work with prerequisites.

Authorize a finite planning allowance and choose a repository. Soda generates native Forgejo work items with acceptance criteria and explicit dependencies. Execution still needs the repository’s authorization, accounts and capacity.

What carries forward

Accepted issue criteria and prerequisite outcomes. Work waits for unresolved dependencies or unanswered requirements.

Example native work items

Example native work items

A dependency plan for the same request

  1. Define the Task record and access

    Store title, responsible person and completion state. HR reads all tasks; teammates read their own.

  2. Implement assignment and completion

    Depends on the record and access rules. HR edits unfinished tasks; only the assignee completes.

  3. Connect the form and task list

    Depends on the record and operations. Verify the accepted behavior for HR and teammates.

Illustrative workflow artifact from the selected department journey.

3 / 6 · The coding agent implements

Build against the accepted rules.

Soda assesses readiness and prepares the repository’s persistent Project and assigned coding checkout. The selected coding agent receives the accepted issue, repository context and authorized account access, then reports the candidate and evidence. Soda OS publishes the pull request.

What carries forward

A candidate pull request at an exact revision. Spaces makes live agent activity and intervention needs visible alongside Forgejo.

Onboarding.can · source excerpt

The task’s completion rule

Given
 role hr
 Task { title:text trim, responsible:user, done:bool=false }
 policy Task read=members where=row.responsible==actor
 policy Task read=hr
 lock Task fields=title,responsible when=row.done
When
 crud Task by=hr fields=title,responsible when=not row.done delete=none
 # Mark your assigned onboarding task complete.
 scenario complete(task:Task) by=members
  require task.responsible==actor and not task.done
  do set task {done=true}
4 / 6 · Another agent checks the candidate

Check the behavior, then correct and review again.

A separate agent session reviews the exact candidate alongside required checks. Findings return to the coding role; revised candidates receive fresh checks, with further independent review when evidence or repository policy requires it.

What carries forward

Findings and review evidence tied to the candidate revision. An agent saying “done” does not establish a completed change.

Illustrative review and correction

Illustrative review and correction

Membership alone must not allow completion

  1. Finding: membership would be too broad

    If a candidate checked only membership, Alex could complete Sam’s task. That would violate HR’s accepted requirement.

  2. Correction: check assignment and status

    The coding role adds the responsible-person check and requires the task to be unfinished, as in the source above.

  3. Fresh review: test all three outcomes

    Sam can complete Sam’s unfinished task; Alex is refused; HR cannot change a completed task’s title or owner. Verify these expectations on the revised candidate.

Illustrative workflow artifact from the selected department journey.

5 / 6 · Forgejo policy governs integration

Integrate when the current policy permits it.

Soda merges automatically when required review and checks pass for the exact candidate and repository policy permits it. If policy requires human approval, that approval is part of the path. Changed or missing evidence prevents integration.

What carries forward

Confirmed integration lets Soda reassess dependent work. Merge and application deployment remain separate actions.

Integration conditions

Integration conditions

The candidate must satisfy all three

  1. The revision still matches

    The pull request’s current candidate is the revision that was checked and reviewed.

  2. Required evidence is current

    The required checks, review and any required human approval satisfy the repository’s rules.

  3. Native merge is confirmed

    Forgejo records the integration and corresponding issue outcome. Creating a PR is not a merge.

Illustrative workflow artifact from the selected department journey.

6 / 6 · HR and teammates use the workflow

One app connects assignment and progress.

The same CanLang source describes the records, access rules, completion action and screen. Try the matching browser example: assign a task as HR, switch to its responsible teammate and complete it.

What carries forward

A tool shaped around the department’s work. The next accepted improvement enters the same factory process.

Try the onboarding example
View CanLangBack to app
Onboarding.canExcerpt

Task completion and reassignment

When
 crud Starter by=hr fields=name,employee,start_date,department delete=none
 crud Task by=hr fields=starter,title,responsible,due_date when=not row.done delete=none
 # The teammate responsible for a task records its completion.
 scenario complete(task:Task,note:text?) by=members
  require task.responsible==actor and not task.done
  do set task {done=true,completed_at=now,completion_note=note}
 # HR can hand unfinished work to another teammate.
 scenario reassign(task:Task,responsible:user) by=hr
  require not task.done
  do set task {responsible}

Onboarding · App preview

Onboarding

Sam

Operations · Starts 8 Mar
1 / 3complete
  • Prepare equipmentAlex · 5 Mar · Unfinished
  • Read safety handbookSam · 8 Mar · Completed
  • Welcome sessionTeam lead · 18 Mar · Unfinished

Illustrative application interface · sample records.

Read the application outcomes

Read the safety handbook → Sam → Complete

  • HR has the overview

    Assign work and update unfinished tasks from the same list.

  • Sam has a clear next action

    See assigned tasks and mark them complete. Alex cannot complete Sam’s work.

  • The rule stays with the record

    Completed titles and owners stay locked. The browser example mirrors these rules with local page state.

Read the factory handbook
Where this walkthrough comes from

The factory sequence and interface names follow the product documents and source code. Application behavior follows the matching complete examples on the CanLang page.

05CanLang app · Continued in the Soda OS factory

Keep deadlines aligned with the start date.

The business changes its requirements. Revise the CanLang app in the same persistent Project, use the factory to develop and review the change, and check what must keep working.

What changes in the application

Illustrative date preview · Sam
MarchCurrentProposed
Sam’s start815
Equipment · −3 days512
Handbook · 0 days815
Fixed · Unchanged18 MarchWelcome session
Completed · Unchanged5 MarchEmergency contacts

A separate unfinished-work illustration: the safety handbook is unfinished here, unlike the completed first-version example. HR previews and confirms these changes together.

Initial rule
Tasks have explicit due dates. Existing tasks retain those dates until HR deliberately converts unfinished work.
New rule
Choose fixed dates or calendar-day offsets from the start date. HR previews and confirms the start date and eligible unfinished relative deadlines together; cancellation preserves both.
What stays protected
Fixed dates, completed dates and completion records do not move. Assignment and selective visibility remain unchanged. Confirmed changes retain before/after dates.

The revised app experience

View CanLangBack to app
OnboardingSchedule.canRule-change excerpt

Preview, confirm or cancel a schedule change

When
 crud Starter by=hr fields=name,employee,department create_fields=name,employee,start_date,department delete=none
 crud Task by=hr fields=starter,title,responsible create_fields=starter,title,responsible,due_date when=not row.done delete=none
 # Preview a start-date change without changing the starter or any task.
 scenario preview_schedule(starter:Starter,proposed_date:date) by=hr
  do
   create SchedulePreview {starter,previous_date=starter.start_date,proposed_date} as preview
   for task in Task as task where task.starter==starter limit=500
    if task.timing==relative and not task.done
     create DeadlinePreview {parent=preview,task,previous_date=task.due_date,proposed_date=add_days(proposed_date,task.offset_days),was_done=task.done,timing=task.timing,offset_days=task.offset_days,already_overdue=task.due_date<local_date(now,"Europe/Brussels"),becomes_past_due=add_days(proposed_date,task.offset_days)<local_date(now,"Europe/Brussels")} as line
    else
     create DeadlinePreview {parent=preview,task,previous_date=task.due_date,proposed_date=task.due_date,was_done=task.done,timing=task.timing,offset_days=task.offset_days,already_overdue=false,becomes_past_due=false} as fixed_line
 # Confirmation rejects a changed task set or stale preview before any final commit.
 scenario confirm_schedule(preview:SchedulePreview,confirm_past_due:bool) by=hr
  require preview.status==prepared and preview.prepared_by==actor
  require preview.starter.start_date==preview.previous_date
  require count(Task as task where task.starter==preview.starter)==count(DeadlinePreview as line where line.parent==preview)
  do
   for line in DeadlinePreview as line where line.parent==preview limit=500
    require line.task.starter==preview.starter and line.task.due_date==line.previous_date
    require line.task.done==line.was_done and line.task.timing==line.timing and line.task.offset_days==line.offset_days
    require confirm_past_due or (not line.already_overdue and not line.becomes_past_due)
    if line.timing==relative and not line.was_done
     require line.already_overdue==(line.previous_date<local_date(now,"Europe/Brussels")) and line.becomes_past_due==(line.proposed_date<local_date(now,"Europe/Brussels"))
     set line.task {due_date=line.proposed_date}
   set preview.starter {start_date=preview.proposed_date}
   set preview {status=confirmed}
 # Cancellation retains the previous start date and every task deadline.
 scenario cancel_schedule(preview:SchedulePreview) by=hr
  require preview.status==prepared and preview.prepared_by==actor
  do set preview {status=cancelled}
 # HR deliberately converts an unfinished task after reviewing its calculated date.
 scenario use_relative(task:Task,offset_days:int,expected_date:date,confirm_past_due:bool) by=hr
  require not task.done
  require expected_date==add_days(task.starter.start_date,offset_days)
  require confirm_past_due or (task.due_date>=local_date(now,"Europe/Brussels") and expected_date>=local_date(now,"Europe/Brussels"))
  do set task {timing=relative,offset_days,due_date=expected_date}
 scenario use_fixed(task:Task,due_date:date) by=hr
  require not task.done
  do set task {timing=fixed,due_date}
 # The teammate responsible for a task records its completion.
 scenario complete(task:Task,note:text?) by=members
  require task.responsible==actor and not task.done
  do set task {done=true,completed_at=now,completion_note=note}
 # HR can hand unfinished work to another teammate.
 scenario reassign(task:Task,responsible:user) by=hr
  require not task.done
  do set task {responsible}
Illustrative CanLang rule-change excerpt · open the complete revised source for records, permissions and interfaces.Read the complete source

Onboarding · Schedule-change example

Onboarding
WorkspacePeople Internal app
Sam / Start date

Review schedule changes

Preview · awaiting HR confirmation

SamNew starter · Operations
Current start8 March
Proposed start15 March
1 overdue task

As of 6 March, equipment preparation is overdue. Its proposed 12 March deadline is in the future. Explicit HR confirmation required.

Deadlines to move2 tasks
Prepare equipmentAlex · 3 calendar days before start
5 March12 March
Read the safety handbookSam · On the start date · Unfinished
8 March15 March
Keep original dates2 tasks
Welcome sessionTeam lead · Fixed date
18 March
Confirm emergency contactsSam · Completed 5 March, 10:24
5 March
Review confirmation details
Date convention
Calendar days, including weekends
Overdue check
Prepare equipment: already overdue on 6 March. No proposed deadlines are in the past. No tasks will be marked complete.
On confirmation
Explicitly acknowledge the overdue task, then save the start date and both relative deadlines together, retaining before and after dates.
On cancellation
Keep the current start date and all existing deadlines.

Preview has not changed the schedule. Fixed dates and completion records stay protected.

Illustrative application interface · a separate unfinished-work example.

Read the full rule, protections and review checks
Illustrative schedule preview · a separate unfinished-work moment

Move the start. Keep the right dates.

Sam's start date
8 March→15 March
HR previews before confirming
Relative · unfinishedPrepare equipment−3 calendar days
Before
After confirmationMoves with start date
Relative · unfinishedRead the safety handbookOn the start date
Before
After confirmationMoves with start date
Fixed appointmentWelcome sessionDate stays fixed
Before
After confirmationUnchanged
CompletedConfirm emergency contactsCompletion record protected
Before
After confirmationUnchanged
Confirm together

Apply the start date and eligible unfinished relative deadlines in one change. Keep the before/after history.

Cancel keeps the schedule

The start date and task deadlines remain as they were. Assignment and visibility never change with these dates.

Existing dates stay fixed until HR deliberately converts unfinished work. Calendar days include weekends. Preview already overdue work and proposed dates in the past for explicit confirmation; never silently move them to today or mark work complete.

  • Calendar days include weekends. Working-day and holiday conventions are separate requirements.
  • HR deliberately converts an unfinished task to a relative deadline and previews its resulting date. Completed tasks cannot be converted.
  • In this separate unfinished-work illustration, Sam's start changes from 8 March to 15 March: Prepare equipment (offset −3) moves 5 → 12 March; Read the safety handbook (offset 0) moves 8 → 15 March.
  • The fixed welcome session stays 18 March. Completed Confirm emergency contacts keeps its original 5 March deadline and completion record.
  • Every start-date edit uses preview and confirmation. Show old/proposed start dates, changed deadlines, unchanged fixed/completed work and past-due effects.
  • Identify already overdue tasks and proposed dates in the past for explicit HR confirmation. Do not move them silently to today or mark them complete. Cancellation preserves the schedule.
Read the revised CanLang source and version coverage
06Your company · Requirements and next steps

Make the rules your own.

Use this example to agree a first useful workflow with its owner and technical counterpart. Identity, purchasing, inventory and other connections need their own evaluation.

Joining tasks
Which work depends on the start date, and which dates must stay fixed?
Responsibility
Who owns each task and its completion evidence?
Visibility
Which starter details does each participant need?
Date conventions
Agree calendar days, working days and holiday exceptions.
Access
How do participants receive their company accounts?
Connections
Evaluate identity, HR-system, calendar and reminder needs separately.

Explore another workflow · Read the factory handbook · Get help