joppa connects commitments, work and evidence. Start by choosing a product from the workspace menu.
A product can span several repositories. They share one requirement tree. Tasks link to repositories: one acceptance criterion may need work in the app, backend and infrastructure.
Switching workspace changes the entire tree, requirements and discussions.
| Level | How to recognize it | Example |
|---|---|---|
| Domain | A business area with a clear decision owner. | Access and subscriptions. Who decides what a subscription includes? |
| Capability | A product ability. Start with “We can…” | We can restore paid access. |
| REQ Requirement | A commitment you can ask “Is this true now?” about. | Paid access persists after signing in again. |
| AC Acceptance criterion | A concrete condition for accepting the requirement. | On iOS, an active subscription unlocks paid features after signing in again. |
“Build a screen” is a task. “iOS” defines the scope of an AC. “Backend” describes where work happens. These are not business domains.
Domains and capabilities organize commitments. Verification and acceptance apply to requirements and their ACs.
The portal is read-only. Open a domain, capability or requirement and choose Copy for agent. Paste the context into your agent chat to discuss it. Changes, discussions, decisions and acceptance are recorded through Joppa MCP.
The copy includes the selected branch, requirement revisions, ACs, checks and history. It names the workspace and item IDs so your agent can read the latest state before making changes.
An agent proposes domains and capabilities from the product and its documentation. The product owner reviews boundaries and decision owners, then confirms the structure. Until then, it stays marked Draft.
People and agents write requirements and ACs together. Each REQ has one owner who responds to suggestions and accepts the result. Legal, compliance and leadership record decisions on the same requirement through MCP.
The agent assesses each AC. Missing information becomes a specific question addressed to someone. Independent, ready ACs can proceed while others await a decision.
A completed task records work done. A passed check verifies one AC against a specific product version. After all checks pass, the owner accepts the result.
The task changes its permissions. The check compares the expected list read, verify with the observed list. An extra delete permission means failure. “Checked manually” without the list is not enough.
If an AC specifies iOS, an agent does not add Android or web. Another platform needs an explicit scope decision.
Saving a requirement or its ACs creates a new revision. Its ACs start without results. Earlier checks and acceptance stay with their original revision.
Comments do not create revisions or automatically block work. Suggestions, replies, changes, checks and decisions keep their author and timestamp. History is never overwritten.