Frequently asked questions

Unlikely. Messy, variable processes are the base case for us. No two teams run delivery the same way. Different hierarchies, three layers here and four there. Different definitions of done. Different names for the same thing, bug or defect or incident depending on who's typing. The object model ships about 80% built for the standard shape of software delivery. The remaining 20% maps your specific hierarchy, your done-states, and your naming, without asking you to standardize first. That mapping is measured in weeks, not the multi-year build people assume when they hear "ontology." If your process were clean and singular, you wouldn't need this. You'd need a dashboard.

The clock starts on data access, not signature. First useful view is one to two weeks after we have credentials and data access. First real insight is two to four weeks. A working object model across two to five systems, with cycle time and rework by stage, fully queryable. A dashboard is not an insight. An insight is a number that explains itself, traced through every system that touched the work. Full rollout scales with footprint. Two or three systems and six to twelve teams take two to four weeks. Twenty-five systems and a hundred teams take roughly six months. Every week you wait is a week of decisions made without the number.

Access to the work systems. A few hours of engineering time per week during setup. That's the list. The raw material already exists in the systems your teams run today. One lightweight plugin in the developer workflow, nothing else to install, no manual tracking, no process rewrite. Where an engagement takes real effort, it's your security review setting the pace, not the integration work.

No. The map and the baseline stand on their own. Bloomfilter measures human and agent work the same way, on the same record. Teams that start before scaling agents get the cleanest before picture, and that baseline is what makes every agent claim afterward provable. Measuring first is the stronger order of operations, not a prerequisite you have to wait on.

Because the object model is the actual product, and it isn't a weekend project. Mapping two systems by hand, Jira and GitHub, looks buildable in a sprint. The moment a third system joins and a fourth team defines "done" differently, the mapping layer becomes a permanent maintenance job. It re-breaks every time a team reorganizes, renames a status, or adopts a new tool. Build-vs-buy math almost never counts that ongoing cost. It counts the first integration and stops there. What you're buying is a pre-built object model that already handles cross-system definition drift, at a maturity that would take an internal team years of dedicated headcount, pointed at exactly this and nothing else, to match. If you have that headcount to spare permanently, building makes sense.

The math is deterministic. Every measure comes from queries against your process data, not a model's judgment. An LLM sits on top to phrase results in plain language, but it formats numbers and never invents them. On benchmark queries, the interpretation layer misreads the question about 1% of the time, and it's tuned to say so rather than guess. For compliance and audit use, the agent-capture plugin provides deterministic attribution end to end.

Performance, adherence, risk, and cost, across the full delivery lifecycle. Underneath those: cycle time, rework, throughput, deploy frequency, process conformance, and the cost of each, broken out by stage, by team, and by model. Every measure is benchmarked against your pre-AI baseline, so the number is a change from a real before-state, not an abstract score.

Yes. The before-state is reconstructed from the event history already in your systems. Commits, tickets, reviews, and deploys from before agents arrived are all still logged. The baseline isn't something you have to start recording on day one. It's already sitting in the data, waiting to be read.

Every number traces back through the systems that produced it. A measure isn't a figure on a slide you have to interview a team to trust. It resolves to the specific tickets, PRs, builds, and agent sessions behind it, across every system that touched the work. Seeing the sources stitched together is the point, not a feature bolted on afterward.

No. Bloomfilter measures agents. Its own assistant, Flora, answers questions about your data, but it doesn't write code, manage tickets, or execute work. If it helps to place it: agents do the work, Bloomfilter is the layer that tells you whether the work paid off. Evaluating it against Copilot or Cursor is the wrong frame. It's what measures them.

No. A dashboard is one surface on top of the data. Bloomfilter is the layer underneath. It's the connected record that dashboards, queries, and reports all read from. A dashboard shows you a number. This is what makes the number trustworthy, because it can trace that number back through every system that touched the work.

By asking. Flora is the natural-language layer over your process data. Instead of knowing which chart to open, you ask a question in plain language and get an answer that already explains itself. Flora builds the graphs and metrics on the fly, and pushes results where you already work: Slack, Teams, a spreadsheet, a slide.

Yes. A process definition is a configuration file, closer to a structured document than code. A senior engineer or delivery lead can author one in about twenty minutes, with a drag-and-drop editor for the process model and saved views for routine reporting. The promise is self-sufficiency. If you had to call us every time your process changed, we'd have built the wrong product.

No. The engagement ends in self-sufficiency. Your team owns the configuration, the data, and the layer. Forward Deployed support continues for new workflows, new toolchains, and the transition to agentic operations, but running the day-to-day doesn't route through us. A new process expectation is a change your team makes itself.

Three ingestion paths, with MCP as a fallback. No custom integration built for your account. API connectors into the systems you already run. A plugin on the coding agent that records each turn: what was proposed, accepted, and discarded, with prompt content off by default. And a pull from wherever you already log this, via OpenTelemetry. MCP covers anything the other three can't reach. All of them exist today. None of them get built after you sign.

The systems teams already run, and the agents already in use. Work and delivery systems: Jira, GitHub, GitLab, Azure DevOps, ServiceNow, Jenkins, CircleCI, Gerrit. Coding agents: Claude Code, Copilot, Codex, Cursor. Data platforms: Databricks, Snowflake. Anything that emits OpenTelemetry. The underlying rule is simple. If a system emits events, it can be a source.

The whole lifecycle. From strategy and specs upstream, through planning, build, review, and deploy, down to support and the tickets a shipped bug creates. Most tools see one slice, usually the coding one. The reason Bloomfilter exists is the connection across all of them, because the cost of a change often lands in a different stage than the one that created it.

The same paths as everything else, in order of preference: a plugin for the major platforms, OpenTelemetry for anything that emits it, and MCP as a universal fallback. A new platform is usually weeks of work, not quarters, because the data model doesn't get rebuilt per vendor. It's a new source, not a new system. Day-one support for everything isn't a promise anyone can honestly make, but the architecture doesn't start from scratch each time.

No. Two to five systems is enough to begin. The 30-day first look uses three. A useful map and a first set of measures come from a handful of connected systems. Coverage expands from there as you add teams and tools. The value doesn't wait on connecting everything first.

That depends on how you deploy. Deploy in your own data cloud or private environment and your data stays in your account. SaaS is available when that fits. Either way, capture is minimal by design. Sensitive content is stripped where it's captured, and prompts and source code can be excluded entirely. What attribution actually needs is the event stream and the ticket it's bound to, not the contents of the work.

It's open source. Your engineers can read exactly what it captures before it touches a single machine. They can fork it and run their own build if they want full control. Regulated environments are the design case here, not the exception, which is why the capture path is inspectable rather than a black box.

Yes, and it's the recommended default. Prompt and code capture can be turned off entirely. The core attribution runs on the event stream and the ticket binding. Token counts and prompt contents sharpen some analytics but aren't required for the measures most teams start with. You decide how much to send, and can start minimal.

Yes. Bloomfilter is SOC 2 Type II audited, and reports are available to customers under NDA.

The capture is deterministic and the log is tamper-resistant. Agent actions, human decisions, and automated steps are recorded in sequence through a path the agents being measured don't control. That's what makes the trail usable for compliance and audit, not just for internal reporting.

The business software where work is officially tracked: project tracking tools such as Jira, code repositories such as GitHub, finance systems such as SAP, customer systems such as Salesforce, and support systems such as ServiceNow. Each one records part of the work accurately. None of them shows the whole picture, and none shows what AI contributed. They are the starting point for everything else in this list.

The usage data AI tools record about themselves: when they were used, by whom, for how long, and how much they cost. Telemetry shows how much AI was used. It does not show whether the work improved. That takes combining it with the systems of record.

A single list of everything that happened to a piece of work, in order. Each entry records what happened, who or what did it (a person or an AI), when, and what it cost. Bloomfilter builds the event log by combining records from your systems of record with AI telemetry. It is the foundation for everything that follows.

Analyzing an event log to work out how work actually moves through a company: the real steps, their order, where work waits, and where it gets sent back. It relies on what systems recorded, not on what a written process says should happen.

The result of process mining: a step-by-step description of how a type of work really flows, with how long each step takes and what it costs. Bloomfilter's process model includes steps done by people and steps done by AI, which is what makes AI's contribution measurable.

A consistent set of definitions for the parts of your work: what counts as a task, a step, a team, a defect, or done. Different teams use different terms for the same thing, and an ontology maps them to one standard. Without it, process models for different teams can't be compared. Bloomfilter builds and maintains it.

Agreed definitions for business measures, such as cycle time or cost per outcome, set once and used everywhere. It sits on top of the ontology, so every report and every AI query calculates a number the same way and the results match.

The information needed to do a task well: what the task is, its history, related work, the rules that apply, and what happened in similar cases. AI models know nothing about your company until they are given this information. The quality of the context largely determines the quality of the AI's work.

The connections between all of the above: which request led to which work, which person or AI did it, what it cost, what was delivered, and what problems followed. Because everything is connected, any result can be traced back to the work and the spending behind it.

The system that builds and maintains everything above (the event log, process model, ontology, semantic layer, and context graph) and keeps it current as work happens. That is what Bloomfilter is. It gives people and AI the same accurate picture of your work, and gives you a reliable measure of what AI costs and delivers.

The most capable AI models available at a given time, made by companies such as Anthropic, OpenAI, and Google. They cost more per task than smaller models. Not every task needs one, which is why measuring results by task matters.

The unit AI usage is measured and billed in, roughly a word or part of a word. Providers charge for every token a model reads and writes. Token counts make AI cost precise. They say nothing about the value of the work, which is why cost needs to be matched to outcomes.

Each time an AI model processes a request and produces a result. It is the ongoing cost of using AI, billed in tokens. Inference spending grows with every person and agent using AI, so it is the main AI cost to manage.

AI that carries out multi-step work on its own, such as completing a task from start to finish, rather than only answering questions. People typically review and approve the work at set points. Because agents now do real work inside your processes, that work shows up in the event log and can be measured like anyone else's.

Short for Model Context Protocol: an open standard that lets AI assistants connect to other software and data. Bloomfilter supports it, so AI assistants can query the context layer directly, for example to ask how a project is going or what a team's AI spending achieved.

Tests that measure how well an AI model does a specific type of task. Public benchmarks measure general ability. Evals built from your own process history measure whether a model does your work well, using real outcomes as the answer key.

Choosing which AI model handles each type of task, based on which one delivers the best result for the cost. It depends on measuring outcomes by model and by task, which comes from the process model and evals. It is how you put the next dollar of AI spending where it returns most.

Additional training that makes an AI model better at a specific type of work, using your own examples. The most useful examples come from your process history: work that was accepted, work that was reworked, and why. Fine-tuned models can match more expensive models on your work at lower cost.

Where your data is stored and processed. Many companies require that data stays inside their own cloud account or region. Bloomfilter can run inside your own data cloud, so your data stays in your account. A hosted version is also available.

The steps a company follows to plan, build, test, release, and maintain software. It is where most companies are using AI agents first, so it is the first place Bloomfilter measures what AI has changed.

The full set of steps around building a product, not just writing the software: researching what customers need, deciding what to build, designing it, building it (the SDLC), launching it, and measuring how it is used. As AI spreads beyond coding to product managers, designers, and testers, the PDLC is where its broader impact shows up.

Short for AI-driven development lifecycle: a way of building software in which AI agents do much of the planning, coding, and testing, while people set direction, review the work, and approve it at set points. It builds on the SDLC and PDLC but changes who does each step. Measuring it means tracking human and agent work in the same process, which is what Bloomfilter does.

Writing a detailed specification first, covering what the software should do, the requirements it must meet, and how to check that it is done, and then having AI agents build from that specification. The specification becomes the main thing people write and review. It makes agent work more predictable and makes it easier to check whether the result matches what was asked for.