The analysis engine
Eight mechanisms, one pipeline.
Each stage has its own mechanism in the analysis environment: an instrument that shows what is happening at that moment, until the artifact is sealed. The same eight mechanisms run below, step by step.
Idea
Loose signals are brought into focus as one central question. Goal, scope and assumptions land in a project brief.
The eight development stages
From idea to monitoring, in fixed stages.
Every project runs through the same eight stages. For each stage it is fixed which question is central, which input is needed, which artifact is produced and which condition blocks the transition to the next stage.
- 01
Idea
- Question
- What do we want to build, and why?
- Input
- Idea, note or problem statement
- Output
- Project brief
- Transition
- Goal, scope and assumptions captured
- 02
Research
- Question
- What do we already know, and what is missing?
- Input
- Project brief, sources, read-only repo
- Output
- Research package
- Transition
- Evidence gathered and weighed
- 03
Analysis
- Question
- Does the rationale hold, and where is the risk?
- Input
- Research package and project context
- Output
- Advisory report
- Transition
- Findings assessed, explicit verdict
- 04
Architecture
- Question
- How do we build this, and with what data model?
- Input
- Advisory report and requirements
- Output
- Blueprint
- Transition
- Design and execution plan complete
- 05
Build
- Question
- Does what we deliver actually work?
- Input
- Blueprint and build prompts
- Output
- Build report
- Transition
- Parts working and traceable
- 06
Validation & security
- Question
- Is it correct, secure and ready?
- Input
- Build report and test criteria
- Output
- Test report
- Transition
- Tests, risks and a go/no-go
- 07
Deployment
- Question
- How do we ship this under control?
- Input
- Test report and release plan
- Output
- Release runbook
- Transition
- Release, rollback and checklist complete
- 08
Monitoring
- Question
- Does it do in production what it should?
- Input
- Release runbook and signals
- Output
- Monitoring report
- Transition
- Metrics and follow-up in place
Processing per stage
Every stage runs the same cycle.
Within a stage the input context is analysed, findings with a verdict are produced, and from those follow tasks, a required checklist, a stage artifact and a build prompt. A gate closes the stage. The results of each stage become context for the next, so the work builds up instead of starting over.
- Input context
- Analysis
- Findings
- Tasks
- Checklist
- Artifact
- Build prompt
- Gate
Executable output
Four concrete results per stage.
Not loose answers, but recorded output you can use directly. The examples below are illustrative.
Stage artifact
A recorded document per stage: project brief, research package, advisory report, blueprint, build report, test report, release runbook or monitoring report.
Advisory report · Analysis Verdict: conditional go Main risk: demand assumption untested
Tasks and recommendations
Concrete, traceable next steps that follow from the findings — each linked to the stage and artifact it came from.
1. Validate demand with 5 user interviews 2. Define data model for the core entity 3. Cut scope to a single flow
Checklist and gate
A required checklist blocks the stage transition until every item is done. The gate is enforced server- and database-side; any override is explicit and auditable.
[x] Sources weighed [ ] Assumptions tested Gate blocked: 1 item open
Build prompt
An executable instruction with context and acceptance criteria, ready to paste into your own development environment. No internal system prompts — just the task and its criteria.
Build the input validation for the sign-up form. Acceptance: empty fields rejected, email checked, errors shown.
Traceability and control
Recorded, blocked where needed, and traceable.
The pipeline is built so you can check what was decided and why, and so incomplete work does not slip through unnoticed.
Recorded decisions
Decisions and stage transitions are recorded, so what was decided and when stays traceable.
Gates that block
Required checks block incomplete stage transitions. The gate is enforced server- and database-side.
Traceable findings
Findings can be traced to the tasks and artifacts they produce, across the stages.
Human review required
Human review is required before important decisions are made. An override is explicit and auditable, with a mandatory reason, and does not rewrite the AI verdict.
Integrations and development environments
What connects today, and how.
Connectors provide read-only context or post updates. Claude Code and Codex collaborate via handoff of build prompts, checklists and artifacts — not a direct two-way API integration.
AI and data transparency
Where AI is used and what happens to your input.
- Where AI is used
- Forge and Flux use Anthropic's commercial API. Optional avatar generation uses fal.ai. Organization-scoped BYOK is built, but configured and checked per pilot.
- Which input is processed
- Forge processes only the text you paste. Inside an enterprise project, connected sources such as read-only GitHub context can be used as additional evidence.
- Voice input
- The microphone button uses the speech recognition built into your browser (the Web Speech API). Your browser does the recognition, not Forenta, and Chrome sends the audio to Google's servers to do it. So what happens to your voice differs per browser. Forenta receives no audio, only the text you choose to keep; that reaches Anthropic only when you ask Flux to structure it. If your browser does not support the API, the button does not appear and there is no other route.
- External model provider
- Core data is intended for an EU Supabase region and the app runs on Vercel. Anthropic and fal.ai may process input in the United States, so not all processing stays in the EU. If you use the voice button, your browser's speech service is added to that.
- Human control
- Human review is required before important decisions are made. Overrides are explicit and auditable with a mandatory reason, and do not rewrite the AI verdict.
- Retention and training
- Forenta does not train its own models on your content. Anthropic states that commercial API data is not used for training by default and is normally removed from its backend within 30 days, subject to safety, legal and contractual exceptions.
- AI output can be wrong
- AI outputs can contain errors or assumptions. Assess results critically and use the review and gate moments to check them.
From analysis to an executable development route.
Start with an idea, a text or a codebase. Forenta analyses it and turns it into artifacts, checklists, tasks and build prompts for your own development environment.
More context: How it works