Questions
Answered plainly, including the awkward ones.
25 questions people actually ask, with the answers we actually give. Several of them are against our own interest, which is the point.
Section 1 · 5 questions
What EigenForge does
What does EigenForge do?
We make the systems an organisation already runs answerable, then make AI usable on top of that, then let agents do routine work inside limits that a named person has set. The order matters. Most AI programmes that stall tried the third step before the first was finished.
In practice that means reading your systems of record where they sit, read-only, and joining them under definitions your business has agreed. Answers are then grounded in those governed records, with policy applied per user when the query runs. Agents come last, each with an owner, a budget, an approval boundary and a signed record of what it did.
We are a Singapore data and AI capability partner. We place our own engineers and specialists inside client teams, and we are accountable for the outcome and not for a licence. You buy one business question at a time, framed in writing before anyone discusses scope or price.
How is this different from a data warehouse programme?
A warehouse requires data to be moved into it. That means a migration, then remodelling, and often a long wait before anyone sees a result. We read the systems where they sit, read-only, with no migration and no change to how they run. If you already have a warehouse, we read it as one more source and do not ask you to unwind it.
The two are not opposed, and a warehouse is sometimes the right answer. Heavy, repeated aggregation over very large tables belongs in a store built for it. Some sources cannot tolerate any extra load. Some history must be copied because the source overwrites it. Where we copy data, we do so for a stated reason and keep the lineage attached.
The practical difference is where the first result comes from. A warehouse programme builds the foundation and then asks questions of it. We start from one question and build only the foundation that question needs, so the second question reuses it.
Is this a platform sale or a services engagement?
A service, delivered on platforms. You buy an outcome — a question answered, a process carried, a control evidenced — and we deliver it on our own production platforms, which we stand behind. You are not handed a licence and left to assemble the value yourself.
Platform licensing is a separate line and any proposal states it explicitly, so you can see what is software and what is work. Where an integrator leads the engagement, the same platforms arrive back to back behind them, and the commercial relationship with you stays theirs.
When are we not the right fit for EigenForge?
There are several situations in which you should not call us.
If your question lives in a single system and that system's own reporting can answer it, use that. It will be cheaper and faster. If you want a licence and no help, we are the wrong shape, because we are accountable for outcomes and not only for software. If nobody can be named as the sponsor who will accept the result, a proof of concept will produce a follow-up meeting and not a decision, and we will say so before starting.
We cannot create data that was never recorded. If the records behind your question do not exist, discovery will tell you that, and the advice may be to start capturing them. We do not offer code translation, we do not build closed-loop control of safety-critical systems, and we will not build an agent that grants or denies an individual's entitlement.
Where a smaller or cheaper route exists, we will tell you in the first conversation.
Who else have you done this for?
We do not name clients. That is a policy, applied equally to everyone, and not an evasion. You will therefore not find case studies, client logos or improvement percentages on this site, and we will not invent them.
What we can offer instead is concrete. At the right stage of a serious evaluation, we can arrange reference conversations on request. We can run an architecture review of your estate against a written list of the questions your architects and security reviewers would ask. And we can run a proof of concept on your own data, inside your own boundary, with the success criterion agreed in writing first.
The third option is the strongest, because it replaces a story about someone else with a test on you. If the proof of concept fails, you will have found that out in a short, bounded engagement, and you keep the written verdict.
Section 2 · 6 questions
How engagements work
What does it cost?
It depends on the question, and we do not publish a price list. The shape is one question at a time, as a defined piece of work with a defined price, and not a commitment to a programme. Discovery and assessment is small, fixed in price and fixed in duration. A proof of concept is short and defined in advance. Platform licensing is separate from our services, and any proposal states it explicitly.
We say the second question costs materially less than the first, because the connections, definitions, catalogue and policy model are built once and reused. We have not published figures for that, so treat it as a design intention that you can test in your own engagement and not as a number we are asking you to accept.
Outcome-linked pricing is available only where a reliable baseline exists. Without one, a share of measured value turns into an argument about measurement, so we will propose a different model. Ask for a written estimate after the framing step. It is yours to keep whether or not you go on.
How do you price what is not built yet?
Honestly, and in the open. Everything we propose carries its real status in the same breath as its name — live, component or design. A live pattern is priced as delivery. A component assembly is a scoped build on parts already running in production. A design is a build, priced as a build, and never presented as available.
If the honest answer is that something does not exist yet, the proposal says so, and says what it would take to find out whether it should. You will never discover the status of a capability by reading the footnotes.
Where should we start?
It depends on what you already know. If you do not yet know which question matters most, start with discovery and assessment, which produces a written readiness view and a prioritised portfolio of questions. If you know the question but not whether AI can answer it, start with a proof of concept. If you know the question but not whether your estate can support it, place a specialist inside the team. If you know both, a scoped delivery under Innovation as a Service is the direct route.
Most relationships begin with one of the first three. The conversation before any of them is not a demonstration. You tell us the question you are asked most often and answer least well, and we tell you whether we think we can help. If there is something to do, we write it up as a framing: the question, who owns it, what you would measure it against, and whether the data is reachable. You keep that document either way.
How long before we see something working?
For a specialist engagement, a first working answer typically arrives in about three weeks. A proof of concept is usually shorter. A scoped delivery depends on the question, and we will give you the realistic range before you commit, not the optimistic one.
Those figures describe the typical case, and several things stretch them. Reaching a system with no interface takes longer than reading one that has a connector. Settling a definition that two departments use differently is often the real constraint, and it depends on people's calendars more than on engineering. Reconciling entitlement models across sources is done by hand today and is the slowest part of many engagements.
The first week is spent understanding how the work happens and where the numbers come from, not configuring software. That can feel slow. It is also what makes the answer that follows one that people can use.
What do you need from our people?
Less than most vendors, but not nothing. For each question we need an accountable sponsor who can accept the result, read-only access to the agreed objects in the relevant systems, and a named point of contact. We need a few short sessions with the business owners of the key measures, so that definitions are agreed once. For specialist work we need a desk inside the team that owns the problem, physical or otherwise, and access to the people who do the work and not only to their managers.
The commitment to watch is the sponsor. A proof of concept with nobody able to accept the result tends to end in another meeting, so we settle who decides in the first hour.
We do not need a system replaced, data migrated, a change to transaction processing, or a multi-year commitment to begin. Your security function is a separate matter. Expect it to want its own time, and bring it in early.
What happens if the proof of concept says we should not proceed?
Then we say so, and the engagement has done its job. A proof of concept ends with a written verdict covering what worked, what did not, what production would take and whether we would advise it. Stopping is a legitimate verdict. The success criterion agreed at the start defines what counts as a partial result and what counts as a failure, so nobody argues about it afterwards.
We accept this outcome because the alternative is worse for both of us. A programme that should not have started consumes budget and goodwill, and the person who sponsored it carries the consequences. A short engagement that stops a bad programme has paid for itself.
You keep the written verdict and the working artefact, and you may use them with anyone, including another supplier. If the data turned out to be unreachable or the definitions unsettled, the document says which, so the next attempt, with us or not, starts further along.
Section 3 · 6 questions
Data, security and sovereignty
Do we have to migrate our data?
No. We read your systems of record where they sit, read-only. Nothing is migrated, nothing is written back and nothing changes in how transactions are processed. The test we suggest for any vendor, including us, is to switch it off and see whether everything carries on exactly as before.
To be precise, that does not mean no copy exists anywhere. Some sources are queried directly. Others are landed for performance, with their lineage attached, and the source system always remains the authority. We would rather say that than make a cleaner claim that fails a technical review.
Reading in place has costs. Analytical queries can add load to a source, so reads may need to go to a replica or be scheduled. Many operational systems overwrite old values, so if you need history that the source does not keep, it has to be captured from now on. And reading does not clean the records. Duplicates and inconsistent codes stay in the source, so quality rules run as the data arrives.
Can we run this with no internet connection at all?
Yes, with limits you should know about. The air-gapped topology runs fully disconnected, including inference on local models. It comes from the same codebase as the other deployments and is not a cut-down edition. A proof of concept can be run in that topology, and we encourage you to test it there.
What does not work offline is anything that depends on the outside. Hosted models are unavailable, so answer quality depends on the models you can run on your own hardware. Data sources outside your boundary are unreachable. Software and model updates have to be brought in by a controlled route instead of arriving automatically.
We have not published a measured comparison of answer quality between local and hosted models, and the gap varies by task. The way to find out is to run your own questions against the models you could host and decide whether the gap matters. For some work a small local model is enough. For multi-step agent planning, test tool-calling reliability before you assume it.
Does our data leave our environment, and who can see it?
In the deployments we describe, no. The engine runs inside your boundary. Authentication uses your existing directory, so there is no separate identity store. Encryption is applied in transit and at rest, with keys under your control. Inference runs against models inside your environment, so content is not sent elsewhere to be embedded or answered.
There are two qualifications. First, you can choose to point the system at a hosted model. That is a configuration choice and it is yours, and in that case the question and the specific material needed to answer it travel to that model. We would recommend it only where your rules allow. Second, the audit trail should live in your deployment and not in a vendor's control plane. Ask every supplier where theirs lives.
Inside the boundary, access is still limited by entitlement. Being inside does not mean everyone can see everything, as the next question explains.
How do you control what different people can see?
Row-level and column-level policy is evaluated when the query runs, per user, against the identity your directory provides. Two people asking the same question get answers limited to what each is entitled to see, from the same layer, with no separate extracts to keep in step. The same policy applies whether the question arrives as SQL, through a BI tool, in plain language or from an agent, because a check that one path can bypass is decorative.
The slow part is not the engine. It is translating written rules into conditions a system can evaluate, and reconciling entitlement models across sources that each have their own. Today that mapping is done by hand during delivery, and it is the slowest part of an engagement. We are working on automating it and have not finished.
You can test this yourself. Take two users with different entitlements, ask both the same questions through every path, and compare the results with what policy says each should see.
Can you show what the system did on a given date?
For agents on Kyros, yes. Each action produces a record holding the request, the evidence relied on, the policy check, the approval, the action taken and a hash chaining the entry to the one before. Deleting or reordering entries is therefore detectable. A decision can be reconstructed from the data as it stood on the relevant date, including which model ran with which prompt and configuration.
There are limits. Reconstruction depends on the underlying systems keeping history. Where a source overwrites old values, we can capture changes from the point we connect, but we cannot recover what was never recorded. Keeping every version of every record is expensive, so decide early which decisions carry the obligation.
The test that matters is whether you can hand an auditor an account of what happened and have it hold up.
What happens if you go out of business?
Plan for it, because it is the right question. What protects you is mostly architectural. Systems of record are read-only, so they are unaffected. Storage uses open columnar formats, so your data stays readable by other tools. Your definitions, ontology, policy model and entitlements are yours. The platform runs on standard Kubernetes on infrastructure you control, so it does not depend on our hosting. Switch it off and everything carries on as before.
Be clear about what this does not cover. ZigmaData and Kyros are partner platforms. If we disappeared, continued support and development would depend on the platform owners, not on us, and we cannot promise their terms from here. Any proposal should state which continuity arrangements apply, and you should ask for them in writing during due diligence.
If we operate the layer for you under AI as a Service, a transition path in-house exists at any point, with a written plan. We say that up front because a client who believes they can leave is far more likely to start.
Section 4 · 5 questions
The technology
Is this just RAG with extra steps?
Partly, and it depends on the question. If your material is mostly documents, such as policies, contracts and manuals, and your questions are about what a text says, plain retrieval over a vector index is a good choice. It is quicker to a first version and cheaper to run than what we build. Use it.
Our approach differs where the answer depends on structure. Relating a customer to their orders and then to their shipments is a join, and similarity search over chunked tables cannot reliably reconstruct one. We model the entities and relationships as an ontology over live records, resolve the question against it and generate a query that is either correct or fails visibly. Policy applies when the query runs, and every figure traces to records. Real questions often mix both kinds of material, so hybrid search has its place.
The way to settle it is on your own questions: a proof of concept measures both approaches on the same material, and the evaluation set stays with you. An ontology also needs an owner to maintain it — that ownership is part of the operating model we set up with you.
How do you stop an agent doing something it should not?
Through several layers, and none of them is a prompt asking the agent to behave. First, autonomy is granted by action class and not by agent, and it is agreed before anything is built. Auto covers routine, reversible actions within set limits. Approve means the agent prepares the action and its evidence, and a named person approves before anything happens. Advise means the agent informs and the person decides. Second, a policy engine on the decision path enforces the gate where the work is done, because scheduled jobs and background processes never come through a front door. Third, budgets decline work at a limit instead of reporting an overrun later. Fourth, every action is signed into a record that can be reconstructed.
A hard limit sits under all of this. No agent grants, denies or alters an entitlement, eligibility or penalty. Where an individual's liability is involved, the default is Advise.
What we have not finished is making bypass architecturally impossible, and not merely unintended. Treat any vendor who says it is solved with caution, including us.
Do agents act on their own?
Only where you have decided they may. Every action class carries a gate — Auto, Approve or Advise — enforced in policy on the decision path, not in a document. Auto is confined to alerts, reminders, routing and low-risk requests. Approve means the agent prepares the work and a named person commits it. Advise means analysis and evidence only, with nothing happening on the agent's initiative.
The gates are agreed before a build starts, and every action an agent takes is signed and recorded, so afterwards you can see not just what was done but under which gate it was allowed. In public-sector deployments no agent decides a citizen's entitlement, eligibility or penalty at any setting — that is a hard limit, not a configuration.
Which model do you use, and can we change it?
We are not loyal to any model. The right one is the smallest that passes your own evaluation, on a licence your legal function has read, within your latency and hardware budget. Specific versions move faster than any document can track, so we confirm a shortlist at design time and record what we tested and rejected. A serious deployment usually uses a mid-size general model, sometimes a long-context model, and sometimes a larger one for agent planning.
Changing a model is a configuration change and a re-run of your evaluation. Grounding, policy, entitlement, evidence and cost control sit in the platform and not in the model, so nothing needs re-integrating. That is the practical meaning of owning your context and renting your intelligence.
The limit is judgement. The boundary between work a smaller model can do and work it cannot is currently set by hand from experience, and we have not yet learned it automatically from usage. We also publish no cost-saving percentages, because they depend on your workload.
What does the system do when it does not know the answer?
It should decline, and say why. A system that answers everything with equal confidence tells you nothing when it answers. We treat a refusal as a designed output with a reason: no evidence, conflicting evidence, no entitlement, out of scope, or beyond an agent's authority. The wording differs for each, because someone told the system does not know behaves differently from someone told they may not see the data. Refusals are logged, because the log maps where your data and scope fall short.
The unsolved part is the threshold. Nobody has a method that works across domains. Model confidence is poorly calibrated, similarity scores do not compare between queries, the cost of a wrong answer varies, and the right setting drifts when the model or the data changes. Set too high, it sends users back to spreadsheets. Set too low, it lets wrong answers reach people who trust them. We have no principled method and have not found one.
So we manage it. We set it by question class, sample refusals and answers regularly, track both error rates together, and revisit it when anything changes.
Section 5 · 3 questions
Working with us
What happens in a first conversation?
It is a conversation, not a demonstration. We ask about the thing that is in your way: a question nobody can answer without days of work, a pilot that demonstrated well and never reached production, a system nobody can get data out of, or a rule about where your data may sit that keeps ruling out vendors.
We will tell you whether we think we can help, what it would take, and when the answer is that you do not need us. If there is something to do, we follow with a written framing: the question, the sponsor, the reference measure, and whether the data is reachable. You keep that document whether or not anything follows.
You do not need to prepare slides. It helps if you can name the question you are asked most often and answer least well, and the systems that hold the pieces. If you cannot name the key that joins two of those systems, say so. That is often the real project.
Can you work alongside our existing integrator and suppliers?
Yes, and we prefer to. We do not compete for the prime role on a transformation. We take a specific, bounded problem inside it, do that well and hand the relationship back. A natural entry point alongside an integrator is migration assurance: reading legacy and target estates side by side, so that reconciliation and parallel running happen on live data and not on sampled extracts.
The governed layer we leave behind is the foundation for analytics, reporting and AI work that somebody has to deliver, and that somebody can be your integrator. Systems of record are read-only and storage is open, so there is no lock-in argument for your architects to defend.
Where this gets difficult is accountability. If several suppliers each own part of an answer, nobody owns the question. We will ask early who the single accountable sponsor is. Agree that before the work starts, not during it.
What will you refuse to do?
Several things, and we put them in writing. No agent we build grants, denies or alters an individual's entitlement, eligibility or penalty. That is a hard limit and not a setting. Sensing and detection is alerting only, with no autonomous dispatch and no closed-loop control of safety-critical systems. Code translation is not offered, though legacy comprehension is. Screen automation is a governed bridge where no interface exists, and we would expect to replace it with a proper integration and would say so in a proposal.
Commercially, we will not offer outcome-linked pricing without a reliable baseline, because it creates a measurement argument that damages a good relationship. We will not publish improvement percentages we cannot defend, and we will not name clients or invent case studies. We will not describe a product as available when it is in development.
If a request needs one of these, we will say so at the start. It is better to hear no in the first conversation than in the fourth month.
Not answered here?
Ask it and we will answer, and if it is a good question it goes on this page.