Questions worth answering

RFI-IRFOS is a registered Austrian not-for-profit (ZVR 1015608684), tracing back to an interdisciplinary research collective founded 2020 in Vorarlberg. We work across ternary AI systems, world-model and evidence-graph research, and agent evaluation, with albert. and DINGIR as the two projects that tie the rest together, unsolicited security research is one strand of that work, not the whole of it. We stay interdisciplinary on purpose, the problems we care about rarely respect the line between one field and the next.

A large language model predicts and generates text from patterns in training data. It is one component we build with and around, not a complete system on its own, which is why we also train albert., our own ternary LLM, instead of treating an LLM as the whole product. A model that only predicts the next token cannot check what it just said against anything real, that check has to come from somewhere else in the system.

An agent combines a model, tools, and observations to pursue a goal and act on its own. We run agents across very different parts of our work: ingesting and validating claims into DINGIR, our world model, running task suites for client agent evaluations, and cross-checking evidence for the security research we publish, always with a human reviewing before anything ships. We keep that human gate because an agent that can act can also act on a wrong belief, and the cost of that mistake is real, not a retry.

A world model keeps a structured, evolving picture of entities, relationships, and causes so a claim can be checked against reality instead of just sounding right. Ours is called DINGIR: a graph that learns its own topology with a neural network and stamps every claim with a ternary state, supported, unresolved, or refuted, never a flat yes. We refuse the flat yes on purpose, most systems that claim certainty are just hiding the cases where they were not sure.

A data warehouse pulls information from many sources into one consistent, queryable place. We build ours from the evidence our own research already produces, world-model observations, agent-safety trajectories, app-behaviour data, and offer it as structured, provenance-tracked data through our Data Solutions line, not just kept for internal use. The work of producing that evidence already happened once, we saw no reason to make a customer pay for us to do it again from scratch.

Our own stack: a ternary logic runtime built from scratch, not borrowed from binary AI frameworks, albert., our self-trained ternary LLM, DINGIR, our evidence-graph world model, Rust and Axum backend services, and the tooling behind 300+ Android security audits. Same team builds all of it, because a system we understand end to end is one we can actually stand behind when something in it is wrong.

Every step of what we build is traceable and inspectable, not hidden behind a vendor black box. We think of ourselves as the whitebox counterpart to systems like Palantir: the same category of capability, but you can see how a conclusion was reached instead of just being told to trust it. That distinction only means something if we hold ourselves to it too, so the same traceability applies to our own findings, not only to the systems we sell.

Yes, and we check them against tampering, not just log them. Our internal systems anchor audit history outside the database itself, so a restored backup or a rewritten row gets flagged automatically instead of being discovered by accident. A log that only the same database can vouch for is not really independent evidence, it is just a second copy of the same claim.

We agree the handling rules with a client before we touch anything, minimise what we collect, and keep test and research data isolated from anything identifying by default. For the unsolicited security research we publish, we go further, no personal data gets published either, only the technical facts and the company's own response, under a fixed embargo, whether they reply or not. Publication was never meant to depend on someone paying us to stay quiet, so it does not.

No. A client's private data, environments, and results stay private unless they explicitly approve publication. Separately, we also run our own unsolicited security research into public apps, and that follows a different, fixed 90 day disclosure clock that applies the same way regardless of payment, a paying client and an unrelated app vendor are not the same relationship and should not sit under the same rule.

No. We audit companies that overreach on data collection, we do not build the overreach ourselves. That line holds regardless of who is asking or what is on offer, because the whole reason our audits carry any weight is that we have never been on the other side of one.

No. Every finding in our security disclosures comes from decompiling a public app binary or reading a company's own published policy, never from tricking an employee or a support contact into giving something up. That standard extends past disclosures too, we do not manipulate people to get information anywhere in our work, whatever the research question.

No. It is the one line no scope negotiation ever moves, regardless of client, budget, or deadline. A boundary that bends under enough pressure was never really a boundary, it was a starting offer.

We design in the answer to "why did the system do that" before writing the first line of code, not after an incident forces us to. Every DINGIR claim ships with its own confidence state and source chain for exactly this reason. Bolting on an explanation after the fact usually means reverse-engineering a story that fits, which is not the same thing as knowing why something actually happened.

Articles 13 (transparency), 14 (human oversight), and 15 (accuracy, robustness, cybersecurity) are reference points we design against directly, not compliance items bolted on once a system already ships. Building to a legal article after launch usually means retrofitting logs and disclaimers around decisions the system already made, which is the same shallow fix as after-the-fact explainability.

Yes. We build task suites around your actual tools, instrument tool use step by step, label failure and safety categories, and hand back a report anchored in real trajectories, not a generic benchmark score. A benchmark score tells you how an agent did on someone else's tasks, not on yours, and those are rarely the same thing.

Yes. Containerised, deterministic resets, controlled test credentials that never touch production, the same setup we use for our own agent-safety evaluations. We hold outside work to the same standard we hold ourselves to, otherwise the word "test" would not mean anything.

Run the same versioned input against the same environment a year from now and get an auditable trail of exactly what changed and why, not just a similar-looking result. A result that cannot be reproduced is an anecdote, however convincing it looked the first time.

We run a root level investigation into the app binary, not a surface scan, contact the affected company through a coordinated written channel with regulators copied in, and publish the findings after a fixed 90 day embargo whether they ever reply or not. Copying the regulator in from the start means we are never the only ones who know what we found, which is the point.

Send us one concrete objective, constraint, or system you actually want to understand, not a wishlist. We scope the smallest useful first step from there, because a first engagement that tries to prove everything at once usually proves nothing well.