Jarvis documentation

Jarvis is the delivery workspace AiM Infosoft runs its client work on. It holds clients, projects and tickets, and it lets AI coding agents pick up a ticket, make the change on a branch of their own, and then stop. A person reads the change and decides. Nothing ships until someone approves it.

These docs cover two things: how to use the workspace, and the delivery approach it was built around. You can read them in either order, but the approach explains why the screens ask for what they ask for.

#What Jarvis does

A client brief becomes a project with a written goal. The goal is broken into outcomes, the outcomes into tickets, and each ticket carries acceptance criteria that say what "done" means. An agent works one ticket at a time on its own branch. When it finishes, it waits at the approval gate with its changes, a screenshot of the site and its own report. Approve it and the change goes ahead as a pull request and, where your project is set up for it, a deploy. Reject it and the change is thrown away.

Around that sit the things a delivery team needs every week: a board with a real workflow, sprints, worklogs, the cost of agent work, client updates and timesheets. There is also a voice screen, which shares the product's name, that answers "how many tasks are left" out loud and can file a ticket from a sentence.

#Start here

• Getting started walks you from your first sign-in to your first approved change: client, project, goal, notes, outcomes, ticket, criteria, agent and approval.

#The approach

AiM Infosoft delivers software around one observation: work rarely goes wrong inside a step, it goes wrong between steps. These pages explain the approach and where each part of it lives in the workspace.

• How we deliver: the handoffs where work breaks, and the five jobs (Define, Plan, Steer, Fund, Ship) that keep it together.
• Goals and notes: the project goal, and the context, constraints, guidance and decisions every agent reads.
• Outcomes and quality checks: lasting capabilities, the six checks an outcome must pass, and the AI review.
• Tickets and acceptance criteria: small, checkable pieces of work, each linked to one outcome.
• Runs and the approval gate: what happens between assigning an agent and the change going live, and who decides.

#Working with agents

• AI coding agents: the agents on the bench, how to choose one, their knowledge and skills.
• What an agent reads: everything an agent is given before it starts, and how to make it better.
• How Jarvis keeps work safe: the promises the workspace makes about agents, approvals and access.
• Jarvis voice: asking about the work out loud, and starting a ticket, client or project by talking.

#Reference

• Connectors: the tools Jarvis works with and what each one lets your team do.
• Glossary: the words this workspace uses.
• FAQ: the questions people ask first.

#The one rule

Every page in these docs comes back to the same rule. An agent proposes, a person approves. Every piece of agent work stops at the approval gate, however small the change and however confident the agent sounds. Voice commands cannot approve or deploy either.

That rule is what makes the rest of the workspace safe to use quickly. Agents can be given real tickets on real repositories because the cost of a bad attempt is a change someone reads and turns down, not a broken live site.

#Who these docs are for

• Delivery leads and project managers will get the most from The approach pages and Tickets and acceptance criteria.
• Engineers and reviewers should read Runs and the approval gate and What an agent reads.
• Anyone new should start with Getting started.

If something here does not match what you see in the workspace, the workspace is right and the page is out of date. Tell us through the contact page and we will fix it.