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. Scaled to footprint. Two or three systems and six to twelve teams: two to four weeks. Twenty-five systems and a hundred teams: roughly six months.

Every week without measurement is a week of baseline lost for good.

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. Nothing new to install in the developer workflow, 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 instrument before scaling agents get the 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.

Two systems mapped 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 internal teams don't reach without years of dedicated headcount pointed at exactly this and nothing else. If you have that headcount to spare permanently, building makes sense. Most orgs asking the question don't, which is usually the real reason it's being asked.

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, it never invents them. On benchmark queries the interpretation layer runs around a 1% error rate, and it's tuned to refuse to 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. 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. No custom integration built for your account.

API connectors into the systems you already run. A plugin on the coding agent itself that captures every turn, what was proposed, what got accepted, what got discarded. And a pull from wherever you already log this, via OpenTelemetry. All three 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 lakes: Databricks, Snowflake, or any store 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.

Three coverage paths, 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.

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.

As little as you want. Everything can stage on a server inside your own network.

Anything sensitive is stripped locally, so only stripped metadata reaches the model. Prompts and source code never have to leave. 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 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.

The capture is deterministic and the log is tamper-resistant.

Agent actions, human decisions, and automated steps are recorded in sequence through a path agents can't quietly edit or disable. That's what makes the trail usable for compliance and audit, not just for internal reporting.