The Inbox App

The Inbox is where decisions are made. Everything InaiBridge's intelligence produces arrives here as a proposal — and stays a proposal until a person decides it.

That is the shape of the product: the engine reads, assesses, and suggests; a human ratifies. Nothing the engine concludes enters your record on its own.

A proposal arrives with its case already made — what the engine found, why it concluded that, what follows if nobody acts, and the underlying signal it reasoned from. Mira sits beside it, scoped to the register you are deciding on, so the evidence can be questioned before it is ratified.

The queues

The Inbox carries six queues, selectable from the type menu. Each asks a different question.

Queue	The question it asks
Risk sign-off	Is this suggested risk real?
Control findings	Has this program breached one of your governance controls?
Lessons learned	Is this drawn lesson worth carrying forward?
Cost allocation	Is this program's cost allocation right?
Close-out attestation	Did this work item genuinely complete?
Attention	The daily watch raised a question about this program — has someone looked at it?

Attention is the one that is not an approval queue. It holds questions the daily watch raised, and acknowledging one records that a named person has seen it. Nothing is approved and nothing is signed, which is why its label says Attention rather than sign-off. It sits alongside the others because a reviewer should only have to look in one place for work.

Each pending item shows the workflow it came from, the gate, how long it has been waiting, and the authority level required to act on it. Resolved items are available on a dedicated history page.

When a queue is empty it says so plainly — every suggested item has been reviewed — rather than showing an empty list.

How a decision works

The loop is the same in every approval queue, and each step exists to stop a decision being made blind.

1. A proposal arrives. The engine raises something as Suggested — a risk it assessed, a control breach it detected, a lesson it drew, a close-out it could or could not substantiate. Suggested means proposed and not yet accepted by anyone.

2. You see the evidence, not just the claim. Each item carries what produced it: the grounded records behind it, the field-level movement that triggered it, and — where the engine was uncertain — an honest note about placement clarity, fuzzy data, or a conclusion resting on a single signal.

To prevent approve-blind decisions, gates that propose a change show a live review-context viewer rendering the full proposed change inside the gate. Where approving would remove existing content, a prominent warning states the removal above the decision controls.

3. You decide, with a reason. Your available actions come from your authority for that item: reviewers may Verify, Acknowledge, or Reject; approvers may Approve, Reject, or Escalate; owners may Approve or Reject. Where a gate requires multiple attestations, live progress is shown (filled of total) and the gate does not resolve until quorum is met. A reason is recorded with every decision.

Each decision is individual. There is no bulk action anywhere in the Inbox — deciding a queue means reading its items.

4. The decision is signed. Every decision writes a tamper-evident, hash-chained record: what was decided, by whom, at what authority, and when.

5. The record is updated. Only now does the proposal become part of your record — a confirmed risk moves into the active register as an open, tracked item; a confirmed finding opens as a tracked governance issue. A rejected proposal is kept too, as an auditable record that it was raised and not upheld, rather than vanishing and leaving a silent gap.

Decisions are reversible where the record supports it: an authored risk can be revoked, and the revocation is itself a signed event rather than an erasure.

The queues in detail

Risk sign-off

Engine-suggested risks, with their source, severity, root cause, and the drift evidence that raised them. Confirming promotes the risk to Authored and into the active register; rejecting soft-archives it as Rejected, keeping the decision auditable without cluttering the register.

Severity is not a model's opinion. It is resolved by a deterministic lookup against your organization's active risk matrix — impact and likelihood mapped to a configured grid — so the same coordinates always produce the same severity.

Control findings

Where the Risk sign-off queue asks whether a risk is real, this one asks whether a program has breached one of your governance controls.

Suggested findings arrive here for a decision. They are grouped by the control they breach, so you review one control's breaches together, and the control's own criteria — the interpretive standard the program is measured against — is shown once above the group. Each finding lists the control's level (levels 4 and 5 gate; levels 1 to 3 are advisory), the program concerned, the finding statement, and whether it was engine-flagged or raised by a person.

You have two actions. Confirm opens the finding as a tracked governance issue. Dismiss closes it and requires a written reason saying why it is not a real breach — the control is disabled until you provide one. Reading the control and the breach before deciding is the point of the surface: a confirmation is a signed governance decision, not a bare yes or no. Each decision is individual; there is no bulk action. Only organization owners and administrators can decide.

Decided findings move to the resolved history, newest first, alongside your other resolved gates. Each entry shows the outcome (Confirmed or Dismissed), the program, the control that was breached, who decided and when, and — where one was given — the dismissal reason in their own words.

Lessons learned

The Inbox also carries a Lessons learned queue, selectable from the type menu. When a risk-carrying program completes, a drafted lesson appears here for confirmation. Each item shows the program (epic), how many risks or close-out references ground it, and whether the draft has been edited. The detail pane displays the full grounding (authored risks with severity, signed decisions that produced them, or close-out references including substantiated_by and cannot_substantiate lists), the drafted lesson text (editable before signing), and the confirm/reject controls. An edit is recorded as an amendment. For candidate trust-close items (hand-closed with no machine evidence), a separate attest action lets a named person stand behind the closure; the agent cannot attest. Confirmed lessons leave the queue and appear in resolved history with their frozen evidence.

Cost allocation

The Inbox also carries a Cost allocation queue, selectable from the type menu. A deterministic proposal appears when a program's money-at-risk (total budget × overdue share) suggests a cost-center allocation. The detail pane shows the suggested amount, the current allocation (if any), and the grounding formula so you ratify a reasoned figure rather than a bare number. You may amend the amount within ratification; both the original proposal and your amendment are recorded. Confirm applies the allocation atomically with provenance. Reject requires a written reason. Each decision is individual; there is no bulk action.

Close-out attestation

The Inbox also carries a Close-out attestation queue, selectable from the type menu. A close-out gate presents the agent's finding (issue key, why the item was held open, delivery evidence or its absence, and any gap) and asks whether you will vouch for closing without that evidence. Approving records a proceeded-on-trust close; declining registers only that you will not vouch and leaves the finding unchanged. The detail pane shows the full captured context so the human decision is informed. Each decision is individual; there is no bulk action.

:::warning Close-out is not programme completion A close-out attestation concerns one work item. It says nothing about whether the programme that item belongs to is finished — and programme completion is not assessed anywhere in InaiBridge, because neither a closure date nor completion criteria are tracked. However many items close, that is never the same claim as the programme being complete. :::

The resolved record

Decided items move to a resolved history, reachable from the Inbox header and listed newest-first. It supports server-side search across every resolved gate in your organization and filtering by type.

Selecting a record opens its full signed lineage, its chain-verification status, and its outcome. Each entry shows what was decided, who decided it, when — and, where one was given, the reason in their own words.

Live updates

The Inbox updates in real time: new items appear and decided ones clear without a manual refresh.

The cost footer

A footer on every Inbox route shows recent AI compute usage for the organization: the rolling window label, approximate USD cost (to four decimals when under one cent), total tokens, call count, and the top three surfaces by spend. An explicit note appears when any models lack published pricing so the figure is understood as a lower bound. Below the cost line the footer carries the suite wordmark and a left-corner link to the third-party licences notice.

Ask Mira about what you're deciding

The Inbox includes Mira, a grounded companion presented as a docked right-hand panel. Mira is grounded on this surface in two layers.

The gate in front of you. With a gate, risk, or control finding selected, Mira scopes every answer to that item — its workflow, the pending decision, the attestation state, or the register — and states that scope in the panel. Explaining the thing you are about to decide is the primary job here, and the answer comes only from the item's real facts.

The organization around it. A decision is rarely legible in isolation, so Mira also carries your live org-wide context on this surface: the risk register, the governance posture, and the money. You can ask what else is outstanding, which programs carry findings, or what the portfolio is exposed to, without leaving the decision.

The two are kept distinct. The gate is the subject; the org-wide picture is background for it, and Mira does not describe one as if it were the other.

And Mira does not fill silence. Every figure carries the source tag it came from, and nothing is cited that is not in the grounding. If the data for a question is not there, Mira says so and names what would be needed. An absence of findings is never reported as a clean state — not knowing and knowing-it-is-fine are different answers, and Mira will not swap one for the other.

You can converse in any of 25 supported languages, use your microphone for voice input, and optionally have Mira's replies spoken aloud. A quiet, rotating daily reflection appears above each session. Suggested questions appear when a record is selected and the conversation has not yet begun.