This site is being rebuilt and some pages are out of date. For current details, write to reach@inorbit.hr. This notice goes away when the rebuild is done.

No analytics unless you allow it, no tracking. This site keeps in your browser the language you pick, the theme, its colour, which site you chose, the currency on the pricing page and that you closed this notice; signing in adds session cookies. The legal page has the details.

Sign in

Early accessInOrbit is opening to software teams, one at a time.

InOrbit d.o.o.Evidence for AI agents

Your AI guesses.
InOrbit gives it evidence.

InOrbit gives AI agents scoped, verifiable evidence from your code, infrastructure, and running systems. Every claim comes with its sources, so agents can distinguish what they know, what they assume, and what they can't prove. Your data stays under your control.

Io, the InOrbit character, ready and available
A real incident on our platform

Why did our build server's disk array go read-only?

  • KnownOne of four drives dropped off at 09:37 UTC, and writes failed in the same second.kernel log
  • AssumedPower saving or heat. Nothing measured the drive before it went.
  • Can't proveWhether the drive or its slot died. That needs a power cycle.

Real incident, 9 October · sensitive details blacked out

Point at or tap an icon to see what it does

0%
01How it fits together

Know when something breaks, why it broke, and that the fix worked

It's one loop instead of six tools. Monitors and incidents tell you something broke. Atlas, which we're building now, works out what the problem touches and which facts the evidence supports. A person or an AI agent proposes a fix, the verifier checks it against what must stay true, and the record is kept.

  8. The record feeds into the next round.

Verify

in part

We check that the original failure is gone and that everything else that must hold still holds, measured before and after.

Runs today
chaos verify measures what a change promises before and after it goes live, and posts the verdict on the pull request. It runs on our own changes, and on yours as a pilot.
Not built yet
Load tests, fault injection, and planted bugs to grade the verifier.
Described in
RFC 0047 · ADR 0019

An incident can start anywhere: a monitor, a person, customer support or a tool you already use. Today incidents open from monitors, automatically or by hand. Every other source will feed the same evidence as it arrives.

02Monitoring and incidents

Know the moment something breaks, and what it cost you

Monitors check your endpoints from our cloud or from the agent inside your network. Every check is kept as evidence: what was checked, from where, when, and what happened. When an incident opens, that evidence goes with it, and its impact is measured from those checks instead of estimated.

your-api · GET /healthz · every 30 s, from our cloud and your agent live

13:50p95 per run14:40

29 minutes · 4.2% of checks failed · p95 of 3.4 s at worst

INC-0142 · your-api preview

  1. The monitor fails from both locations
  2. The incident opens and pages the people on call
  3. Acknowledged from the lock screen
  4. Resolved, with the impact measured from 58 checks
  5. The postmortem is written on the same monitor's page

Coming next: with Atlas, an incident will show what it touches and which possible causes are still open.

example data

Your existing tools add to the same evidence Adding a connection doesn't require any change to the core. Planned: each connection says what kind of evidence it provides, and Atlas decides what that evidence can prove.

  • GitHubVerdicts on pull requests: in InOrbit's own repository today, for customers soonin part
  • Kubernetes · EnvoyRead by the agent for Atlasin development
  • incident.ioThe same incident in both toolsin development
  • Grafana · Loki · Datadog · PagerDuty · cloud · your own toolsThrough connections anyone can buildcoming
  • Notion · Confluence · Google Docs · GitBook · your docs sitesYour internal docs, read by your own agent for Atlascoming
03Atlasin development

See how your system really works, and the proof behind it

We're building Atlas to read your code, configuration, live traffic and decisions, and turn them into facts. Each fact names the evidence it needed and what it still assumes. When two sources disagree, you see both. When nothing has looked yet, there's no fact, and Atlas tells you what would settle it. It never gives you a confidence score.

atlas / inorbit / GET /v1/status5d885e97 · 2026-10-09 23:44 UTC

The pathpick a fact to see its proof

  1. clientbrowserGET https://api.inorbit.hr/v1/status
  3. cdncloudflaretls, proxied
  5. edgecaddyapi.{$BASE_DOMAIN} devops/edge/Caddyfile:121
  7. proxyenvoyvirtual_host all devops/envoy/envoy.yaml:3109

  8. envoy → protocolroutes_to@1verified

    1. configdevops/envoy/envoy.yaml:3946The route GET /v1/status in the all virtual host goes to the cluster protocol.
    2. runtimetbd_requests_total{route="/v1/status"}protocol counted 35 answers of 200 on /v1/status, across its 2 replicas, since 23:11 UTC.

    Two independent kinds of proof agree, so the fact is verified.

  9. gatewayprotocolTranscoder::from_config crates/protocol/src/transcode/mod.rs:230
  11. serviceconnectionsget_public_status_now crates/connections/src/service/status.rs:54
  14. storepostgresmigrations/20261003164237_connections_monitors.sqlconnections.monitors:11connections.monitor_runs:41
  16. pool · instance ?

7 facts · 3 verified · 4 supported · 1 no claim yet

Fact kinds
  • routes_to@1 a route in configuration
  • calls@1 a call resolved in code
  • connects_to@1 traffic seen live
  • reads@1 a query and its table's schema
States
  • verified two independent kinds of proof agree
  • supported one kind of proof
  • no claim yet nothing observes it, so no fact
Real files and real counters from our own platform, at commit 5d885e97. The repository is private, so each path is shown as text.

It's not a dashboard: it tells you what's true and why. It's not an AI code reviewer: a model can suggest things, but only evidence changes a fact. It's not a docs generator: anything that changes gets checked again.

From code

Compilers and parsers, in every language InOrbit supports. A model only reads where they can't, and that's labelled.

From what runs

Kubernetes, Envoy routes, network policies and traffic, read by the agent inside your network. It only reads.

From your decisions →

Your PRDs, ADRs and RFCs in Decisions, each linked to the code and services it covers.

comingAtlas will also read your internal docs, such as Notion and Confluence, through your agent.

Where Atlas standsRFC 0086 · PRD 0001 · ADR 0001–0064

  1. 01The proof coreFacts, proof rules and certificates. It caught all 26 of 26 planted bugs.done
  2. 02The storeEvery fact, with when it was true and when we learned it.done
  3. 03Readers in the agentBuilt: it has read 4,796 records from our own platform.now
  4. 04The two exit testsFind one true thing nobody told it, and find a planted contradiction.next
  5. 05The map in the consoleOn your system, for partners first, then the reth showcase.next
04A real verification

The first time we checked our own release, it caught a problem

On 4 October we checked one of our own releases before and after it went out, 39 minutes apart. Three things held up. One check that passed before the release failed after it, so the verdict was fail. We didn't explain it away or round it up. Here's the full record.

The run, as the terminal printed it (excerpt)
$ mise run verify:before 251
pull request 251 at 26202e4cf865: 4 claims
  surface-1    `http_healthz` passes
  surface-2    `grpc_protocol_health` passes
  contract-1   the public API is unchanged
  text-1       chaos verify posts a verdict on this pull request after it rolls
PASS  http_healthz           http        206.5 ms  200 OK {"status":"ok"}
PASS  grpc_protocol_health   grpc        115.0 ms  status 1
PASS  http_mcp_tools         http        165.0 ms  tools=21
# 41 more checks, every one passed
44 passed, 0 failed
# 39 minutes later, after the change rolled
$ mise run verify:after 251
PASS  http_healthz           http        308.0 ms  200 OK {"status":"ok"}
PASS  grpc_protocol_health   grpc        167.9 ms  status 1
FAIL  http_mcp_tools         http          8.3 ms  an anonymous tools/list answered 401 … want 401 naming resource_metadataaddress shortened
# 41 more checks, every one passed
43 passed, 1 failed
### Verdict: fail
verdict posted on pull request 251

The record

Pull request #251, head 89339c77f63f

Verdict: fail

What we expected

  • passhttp_healthz passes200 in 308 ms
  • passgrpc_protocol_health passesserving, in 168 ms
  • passthe public API is unchanged98 operations compared, none changed
  • not measuredthe verdict is posted on the pull requestplain-language claims are never measured

Checked by

  • failnothing that passed before fails now44 checks passed before, 43 after: http_mcp_tools failed
    Why it failed

    The http_mcp_tools check had been updated by an earlier pull request that was merged but not yet live, so the verifier expected a sign-in answer the platform didn't give yet. The change we tested didn't break it. The verdict still says fail, because it records what was measured, and a person decides what that means.

  • not measuredno new findingno load or faults on a bench yet
  • n/amust-fail checks still failthe change named none

This record is an unsigned draft. We only observed; we didn't plant a known bug to grade the verifier against. Planted bugs, signing and storage aren't built yet (RFC 0046, RFC 0047).

05Early access

Bring one real incident. See what your AI can prove.

Pick something that actually happened to you: an outage, a slow release, a change you weren't sure about. We connect to your system read-only and work through it with you. You see what your AI can show with evidence, what it's only assuming, and what it can't prove yet.

  1. 01

    Pick one incident or change

    You
    Pick the incident or change
    InOrbit
    Agree the scope in writing

  2. 02

    We connect, read-only

    You
    Give read-only access
    InOrbit
    Connect monitors and the agent
    What you keep
    sources

  3. 03

    Your AI works from the evidence

    You
    Ask your AI, as you normally would
    InOrbit
    Gather evidence, before and after
    What you keep
    evidence

  4. 04

    You get the evidence

    You
    Read the write-up
    InOrbit
    Hand over the full record
    What you keep
    the record

What you get

You get one record per change, measured before and after it goes live. This is the record from our first real run. Rows marked planned aren't built yet.

Today
Change
pull request #251 in InOrbit's own repository
Before, after
head 26202e4cf865, read at 13:25 UTC and again at 14:04 UTC, after it rolled
Made by
whoever made the change, according to the pull request. A person and an AI agent are held to the same record.
Measured with
read-only checks against the live platform, 44 before and 44 after. Load and fault tests on a copy of your deployment are planned.

Claims, each measured

  • passhttp_healthz passesbefore: 200 in 206 msafter: 200 in 308 ms
  • passgrpc_protocol_health passesbefore: serving, in 115 msafter: serving, in 168 ms
  • passthe public API is unchangedbefore: 98 operationsafter: 98 operations, none changed
  • not measuredchaos verify posts a verdict on this pull request after it rollsnon-blocking, declared before the runbefore: stated in wordsafter: plain-language claims are listed but never measured, and never count as a pass
  • plannedp95 of an endpoint stays under a limit at a stated loadbefore: planned: no load on a copy yetafter: planned

What every change is held to

  • failnothing that passed before fails now44 checks passed before, 43 after: http_mcp_tools failed
  • plannedno new findingplanned: load tests and injected faults on a copy aren't built yet
  • n/achecks that must fail still failthe change named none

Grading the verifier

Planned: we'll break changes on purpose, with a label the verifier can't see, so we can grade the verifier itself. Not built yet (RFC 0047).

Signed
not built yet: records are unsigned drafts today (RFC 0046)
Public timestamp
not built yet (RFC 0071)
Links
the run's files (before, after, the comment) and the comment on the pull request

Verdict fail

fail. A check that passed before failed afterwards. The change we tested didn't cause it, but the record still says what was measured.

Every value comes from run #251 on InOrbit's own repository. On your system, the record holds what was measured there.

  1. 01 Pick one incident or change. Something real from the last few weeks, or a change you're about to ship. We agree the scope in writing before we start.
  2. 02 We connect, read-only. Monitors and the agent inside your network gather evidence from your system. Nothing is changed, no load goes onto production, and your data stays with you.
  3. 03 Your AI works from the evidence. Your assistant connects through MCP and answers from the evidence InOrbit can show. For a change, we check before and after it goes live.
  4. 04 You get the evidence. A clear write-up: what happened, what's proven and by what, what's still a guess, and whether the fix held. You keep the full record.
or book it by e-mail

The calendar is Calendly's booking page. It only loads from Calendly when you open it, and nothing from Calendly runs on this page before that.

06What works today

What you can use today, and what's still coming

Live means anyone with access can use it today. Preview means it works, but only for admins and partners or as a pre-release. Coming means we've written it down and built part of it. In development means we're building it now. Pick a box to see what it does.

livepreviewcomingin development

You

Your teamYour AI assistantYour AI agents

How you reach it

Products

chaos verify

preview

We measure what a change promises before and after it goes live, and post the verdict on the pull request. It runs on our own changes today. Load tests, fault injection and planted bugs come next.

Use it today
It runs on our own changes today. On yours, it starts as a pilot.

RFC 0047, the first complete loop →

What's kept

07Prefer to try it yourself?

Start on your own in three steps

  1. 01Get an account

    We're opening InOrbit to teams one at a time. Ask for access, and tell us what you'd like to try first.

  2. 02Install and sign in

    Install the iohr command line (0.1.0-alpha.13). The tools page covers other systems.

    brew install inorbithr/tap/iohr
    iohr login
    See every way to install

  3. 03Watch your first endpoint

    iohr api GET /v1/me

    Point a monitor at one of your endpoints and watch the first checks come in.

    Monitor an endpoint

Also on your phone and in your browser

  • Phone apppreview · TestFlightMonitors, incidents and document reviews on iPhone and Android. Acknowledge an incident from the lock screen.
  • Browser extensionpreviewRecord a flow you walk through and turn it into a test. It never records what you type.
08Open source and public RFCs

We write every design down before we build it

87 of our RFCs are public, each with a dated log of what shipped. The rest, along with our ADRs and PRDs, are internal. All of them live in Decisions, the same product you'd use for your own. The agent, the SDKs and the command line are open source; the platform isn't.

Latest updates

  • 2026-10-09 · RFC 0078.1

    One incident in incident.io and InOrbit

    PRD 0009 (incident tools as a two-way home) builds on this RFC: incidents in from every source, the InOrbit app in the incident channel wit…

  • 2026-10-09 · RFC 0077.1

    The agent reads the code and proposes proved fixes

    Models and code reconciled with RFC 0097.7 and the site (#687): third-party providers are the customer's own connections and keys, routed b…

  • 2026-10-09 · RFC 0077

    The GitHub agent, fixes that find their incidents

    The states a fix moves through, from proposed to resolved, are RFC 0101.

Our open source →

InOrbit d.o.o., Croatia, founded in 2018. Who we are, how we handle your data and which gaps we still have, all on one page. Company and trust →

Book a call
calendly.com/nevio-vesic/30min
What to tell us
Tell us which system you run and which change you'd like proved. Nevio reads and answers every message.