> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oktolabs.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Cards

> The Pulse work unit: implementation, bug, and test cards with validation evidence.

# Cards

You can use cards as the executable work units in Pulse. A card carries status, owner, dependencies, links back to spec evidence, comments, Q\&A, attachments, conclusions, and validation records.

## What is a card

A card is the smallest delivery object an agent should implement or validate. Cards can be created directly, derived from specs, assigned to sprints, and linked to spec evidence.

## Card types

| Type     | Use it for                                                                               |
| -------- | ---------------------------------------------------------------------------------------- |
| `normal` | Standard implementation work.                                                            |
| `test`   | Test-only work. Test cards can bypass the normal task validation gate.                   |
| `bug`    | A defect. Bug cards require bug-specific fields and should preserve root-cause learning. |

## Bug card specifics

Bug severity is explicit: `blocker`, `critical`, `major`, `minor`, or `trivial`. A bug card should include reproduction steps, expected behavior, actual behavior, suspected area, and a failing test scenario before moving into implementation.

## States

| State         | Meaning                          |
| ------------- | -------------------------------- |
| `not_started` | Ready but not picked up.         |
| `started`     | Claimed or started.              |
| `in_progress` | Active implementation.           |
| `validation`  | Waiting for reviewer validation. |
| `on_hold`     | Blocked or intentionally paused. |
| `done`        | Complete.                        |
| `cancelled`   | Should not proceed.              |

The normal gated path is `not_started -> started -> in_progress -> validation -> done`.

## Card priority

Use priority to communicate sequencing pressure, not importance theater. Supported values are `critical`, `high`, `medium`, and `low`.

## Card knowledge, mockups, and architecture

Cards can copy knowledge, Q\&A, mockups, and architecture from the spec or attach their own. Copy from spec when the context is already approved. Attach directly when the implementation discovers card-specific evidence.

## Dependencies between cards

Use dependencies when one card cannot be completed until another lands. Dependencies should be concrete: API exists, schema migrated, test fixture added, deployment flag available.

## Task conclusions

Before a normal card can move into validation, the implementer must supply an execution conclusion: completeness `0-100`, drift `0-100`, and written justification. This turns the handoff into evidence rather than a status flip.

## Validation records

Task validation is append-only. `okto_pulse_submit_task_validation` checks confidence, completeness, drift, and threshold violations, then routes the card to `done` or keeps it in `validation`.

## Traceability

Use traceability links so a card can prove what it implements:

```text theme={null}
okto_pulse_link_task_to_scenario
okto_pulse_link_task_to_rule
okto_pulse_link_task_to_contract
okto_pulse_link_task_to_tr
```

## Related pages

* [Validation gates](/concepts/validation)
* [Sprints and cards tools](/reference/mcp/sprints-cards)
* [Card and KG flags](/permissions/card-kg)