Introduction
The project card is where a project’s own details are stored. It sits below the Compass and is organised into groups of fields. This article will discuss each group in detail and explain what it is for and what the fields include.
You will return to this card throughout a project, so it is worth reading once in full beforehand.
General
General identifies the project and tells you what it is waiting for. Next Step mirrors the guidance shown on the Compass, so the card and the Compass never tell you different things.
| Field | What it holds |
| Next Step | The next required action for this project, mirroring the guidance shown on the Compass. |
| Project number | The identifier for the project. |
| Description | A short description of the work, used to recognise the project in the Projects list. |
| Output name | The name of the application ARVO produces. It becomes part of the generated application’s identity. |
| Publisher | The publisher recorded against the generated application, and also part of its identity. |
| Object prefix | The prefix used for the objects the project generates. |
| Design-document indicator | Shows whether the solution design document has been attached. |
The output name and the publisher become part of the generated application’s identity, so naming should be consistent. Agree a convention with your team and keep to it across projects rather than deciding it project by project.
Analysis Context
Analysis Context records what ARVO knows about the customer situation and the people involved.
| Field | What it holds |
| Industry | The customer’s industry, which helps ARVO understand the customer situation. |
| Company-context indicator | Shows whether company context has been supplied. |
| Role-context indicator | Shows whether role context has been supplied. Role context is used to define the personas involved later in testing. |
Industry and company context help ARVO understand the customer situation, and role context is used to define the personas involved later in testing. If either indicator is off, consider whether adding that context would improve the work that follows.
Gap decisions and consultant notes
Every gap found on a project carries a decision. The options are to build it, defer it, reject it, do it manually or use existing IP, so the way each gap will be handled is visible on the project rather than stored as an idea in someone’s brain. A specific gap can also be excluded from scope, and once it is excluded it takes no further part in the rest of the ARVO Studio process.
Consultant Notes can be recorded against gaps, training documents, functional design documents and technical design documents. A note is your own comment on that artefact, and it is taken into account when the artefact is next regenerated, so a correction is recorded once rather than repeated every time the work is refreshed.
Tokens
The Tokens section is where you compare the estimate with actual usage. The estimate is described in Token Estimation, and this group shows what has been consumed against it as the project progresses.
The estimate is presented as an envelope rather than a single figure: a minimum, an expected and a maximum, shown beside the generation approval so that you can see the range before you commit to it. Actual consumption is reconciled against that envelope afterwards, which is what this group lets you compare as the project progresses.
| Field | What it holds |
| Branding template | The branding template used for the project. |
| Source filename | The filename the estimate was based on. |
| Estimated token range | The estimated envelope for the project, shown as a minimum, an expected and a maximum figure. |
| Estimate stage | The stage the estimate relates to. |
| Tokens consumed | Actual usage so far, for comparison with the estimate. |
| Note | Any note recorded against the estimate. |
Important: AI runs on the customer’s own Azure AI Foundry deployment or Anthropic account and is paid for by the customer. The usage shown here is usage on that account.
Self-Healing
The Self-Healing section holds two settings, and both are best understood at the level of the outcome they produce rather than as anything you need to tune constantly.
| Field | What it holds |
| Max Repair Loops | How many limited repair attempts ARVO can make before stopping for human review. ARVO never forces a failing run through. |
| Test Fault Injections | Deliberate faults used to confirm that the test suite can detect failures. |
IP Guardrail
The IP guardrail exists so that a project does not quietly rebuild something the customer could already have. If a requirement appears to duplicate an existing product capability, ARVO recommends procuring rather than rebuilding.
| Field | What it holds |
| Guardrail override reason | The reason recorded when the user proceeds with building something ARVO has recommended procuring. The reason becomes part of the audit trail. |
You are not prevented from continuing. If you decide to proceed anyway, you must record a reason, and that reason becomes part of the audit trail. Define it as you would want it read months later by someone asking why the work was built rather than procured.
Quick check
The card is complete when General shows the description, output name, publisher and object prefix along with the design-document indicator, and Next Step is aligned with the step highlighted on the Compass.