Theta One product · Beta now · GA targeted Autumn 2026
Etheria takes a signed-off requirement and gives your engineers a pull request to review.
We operate it on your project. There is nothing to install, and nobody on your team gets a login. Etheria is in Beta: there are no public client references yet, and general availability is targeted for Autumn 2026.
etheria.ro is the product site — the pipeline step by step, where Etheria fits and where it does not, and the Beta walkthrough booking. This page answers the other question: who is behind it.
What you are actually buying
Etheria is a way of delivering software, not a licence or a seat. An analyst runs the requirements session and writes the specification; someone signs it off; an AI agent writes the code against that specification on our infrastructure; a Tech Lead reviews what comes back against the test output; and the change arrives in your repository as a pull request that your own engineers merge or refuse.
Nothing is installed on your side. The platform is ours to run, which is also why there is no client login — see the Beta section, because that is a real gap and not a design principle.
Commercially it sits inside an ordinary delivery contract with Theta One Digiplex S.R.L. and is priced on the scope of the work rather than per seat, per user or per token.
How a requirement becomes a pull request
Eight steps, in order. If any of them reads as vague, say so on the call and we will show you the screen it happens on.
The project is indexed before anything is written.
We build a knowledge index scoped to your project alone: the project overview, the milestones, the current work items, and any documents you hand over — architecture notes, API contracts, existing specifications. Each source is hashed, so re-syncing only re-uploads what changed, and material edits mark the project out of sync until it is rebuilt. The index is held in OpenAI's vector store service. That is a data-handling fact and you should have it now rather than in a questionnaire three weeks later.
An analyst runs the requirements session with the model in the room.
The Technical BA works the requirement through with a model that has your indexed project available to it, so it argues from your system rather than from the internet. The session output is parsed into structured task proposals — title, description, acceptance criteria — which the analyst edits, discards or accepts. Saving proposals into the backlog is an explicit action by a named person. Nothing arrives in the backlog because a model produced it.
A person moves the work item to READY_FOR_DEV. That is what dispatches the agent.
Work items move BACKLOG → READY_FOR_DEV → IN_PROGRESS → READY_FOR_REVIEW → DONE. The transition into READY_FOR_DEV is what queues an agent run, and that transition is made by a person, either directly or by approving a review. The model does not decide that a specification is ready to build.
The run happens on our infrastructure, on its own branch.
The agent service clones the repository, cuts a branch named agent/<task-id>, and applies its edits there. Code changes run through OpenAI's Responses API or Anthropic's Claude agent SDK, selected per project. The run is recorded as an AgentRun with its own status and log, and its state maps back onto the work item: a failure returns the item to IN_PROGRESS with the failure reason attached, not to a silent dead end.
Build and test run in a container that is not the application.
Setup, build and test commands execute in a runner container held separate from the API and the database. Network access for that container is a configured setting rather than something that is always on, which means a build that needs to reach a package registry is a decision someone made and can point to.
The run ends at a pull request. There is no merge step in the pipeline.
On a successful run, where the engagement is configured for it, the agent commits, pushes the branch and opens a pull request on GitHub. Where it is not, nothing leaves our infrastructure and your repository is never written to. There is no merge step in either configuration. Your branch protection, your required approvals, your CI checks and your reviewers apply to that pull request exactly as they apply to a contractor's.
A named person approves before the work item is done.
A successful run moves the item to READY_FOR_REVIEW, and it cannot leave that state on its own. A Tech Lead reads the diff and the test output and records APPROVE or REJECT against the work item. REJECT carries a reason and sends the item back. Then your engineers review the pull request. Two reviews, both by people, both recorded.
Every write is logged, and deletes are soft.
Changes to users, customers, projects, milestones, work items, reviews and agent runs all write an audit entry. Records are soft-deleted rather than removed, so an item's history outlives the item. The delivery record for one work item reads: the requirement it came from, the specification that was approved, the run that implemented it, the test output, the pull request, and the names on both approvals.
Technical BA and Tech Lead are roles in Etheria, not headcount. On an engagement run by one practitioner they are the same person in both roles, and the record says so — the approval carries the name of whoever gave it. What does not change is that the approval is a recorded act by a person, and that your own engineers review the pull request afterwards.
What Beta means if you start now
What exists, what does not, what we would need from you, and the part you are actually taking a risk on.
Working today
- The workspace: role-based access, per-project membership guards, customers, projects, milestones and the work-item board.
- Requirements sessions against a project-scoped knowledge index, producing structured task proposals that a person saves to the backlog.
- Agent runs on OpenAI or Anthropic models, in a separate runner container, with branch and commit, and with push and pull request to GitHub where the engagement is configured for it.
- The APPROVE / REJECT review gate, with the reason recorded, and the audit trail underneath it.
- Run monitoring: task clusters, run status and logs, polled and visible while a run is in flight.
Not built yet
- No client login. Etheria has three roles — ADMIN, TECH_BA, TECH_LEAD — and all three are ours. You see the work through your own repository, your pull requests, and the delivery record we export and walk you through.
- GitHub today. The pipeline runs against GitHub. If your source control is somewhere else, ask before you rule it out. It is a scoping question and you get a straight answer on the first call.
- No on-premise deployment has shipped. It is possible in principle, and it is scope agreed before you sign, with a date and a price attached.
- No SOC 2, no ISO 27001, and no third-party penetration test of the platform.
- No published SLA and no status page.
- No public client references. See the last paragraph of this section.
What we would need from you
- A repository we can clone, and a build and test command that runs in a container with nobody present. If your build needs a VPN, a licence server, or an artifact someone signs by hand, tell us on the first call. That constraint decides the fit faster than anything else on this page.
- A named person who can approve a specification and a pull request. The pipeline stops at a gate with nobody standing at it, and that is by design.
- A first work item that is real but is not on your critical path.
- Permission for a machine account to clone, push a branch, and open a pull request.
What you are actually risking
The honest risk is throughput, not safety. A change reaches your main branch only through a pull request your own engineers approve, under your own rules, the same as any contractor's — so an unreviewed change is not the exposure.
What Beta does not guarantee is pace. A run can fail. A model can produce a diff that is not worth the time it takes to read. When that happens the answer is that an engineer writes the work item by hand and you still get the work item, on the same specification, through the same gates. What you are risking is that the pipeline saves us less time than we expect on your particular codebase, and that the delivery looks much like an ordinary one. That is a commercial disappointment, not an incident.
The security documentation
An automated process holding push access to your source control is a supply-chain question, and review gates are not an answer to it on their own. The document that answers it properly is being written: the access model and what the git credential can and cannot do, execution isolation, the subprocessor list, data residency and retention periods, and the model providers' training terms on the accounts we actually use. It is not finished, so this page does not summarise it. If you need it to evaluate a pilot, ask and we will send it the day it exists.
One more thing, because it changes how you should read the rest of this site. The client logos elsewhere on thetaone.digital are Technical Business Analysis engagements. They are not Etheria customers. Etheria has no public client references yet. When there is one, it will carry a name and written permission from the client.
Etheria is the analysis practice, industrialised
The larger part of Theta One is Technical Business Analysis: sitting inside a client's delivery team, writing the specifications that team builds from. The wait between a signed-off requirement and someone picking it up is usually longer than the build, and the third revision of an acceptance criterion nobody agreed on costs more than either.
Etheria takes the mechanical parts of that job (indexing what is already known about the system, drafting task proposals out of a requirements conversation, cutting the branch, running the tests) and hands them to a machine, while leaving every judgement call attached to a name. The gates in the pipeline are the gates a good analyst already runs by hand. The method is not new. What is new is that the wait between the gates is close to zero.
If Beta is more risk than you want
Then do not take it. Start with an embedded Technical Business Analyst on an ordinary contract. That is our main business, and it commits you to nothing about AI at all. You get the same governance: specifications with acceptance criteria and edge cases, a traceable record from requirement to test result, and a named person accountable at each step. Etheria is opt-in on top of that, later, on a work item you pick. Most of what this page describes started as a manual checklist inside exactly that kind of engagement.
etheria.ro is where the product lives
etheria.ro carries what this page deliberately does not: the pipeline step by step, the four points where a person has to sign, where Etheria fits and where it does not, the Beta programme terms, the product FAQ, and a cost calculator. The security and data-handling documentation publishes there too, once it is finished. Same product, same company. thetaone.digital stays authoritative for anything about the firm, the contract and the people.
A walkthrough is a screen share of one real work item going through the pipeline: requirements session, agent run, test output, the approval gate, and the record it produced. About an hour. No repo access and no NDA needed to attend.