Enterprise AI needs more than a chat box.

A useful EKA answer may need to show all of this at once:

• the enterprise object it resolved, and which key that is
• which source system a fact came from, and whether the value is canonical or source-native
• which document passage supports a statement
• which calculation was executed, over which rows
• that a downstream business record is absent
• that a capability is not available on this subject
• that part of the answer is restricted from the person reading it
• whether the result is complete, partial or unavailable

None of that survives being flattened into a paragraph of generated text. So the Agent Experience is conversational at the top and structured underneath: prose a person can read, over records, evidence, calculations and a stated result.

This capture replays a previously executed real EKA run — the evidence pack's own guide-v4-01-closed-won-no-erp — so the page does not depend on a model answering the same way twice. The runtime produced this answer on the committed estate; the replay calls no model, which is what the frame's Model · scripted (captured run) line means.

Organization · Opportunity · Sales order · Source record · Document
        ↓
    Ask EKA
        ↓
 Sidecar, opened with the page it was opened on as its context

Opening a Sidecar conversation in the Workspace continues it. It is not copied.

All three replay guide-v4-01-closed-won-no-erp — the approved run EKA-GUIDE-01, whose recorded page context is exactly the one this Day-0 page declares. The record was chosen for that reason rather than for how it looks.

Below 1024px it becomes an overlay

There is no room for a 400px panel beside a phone-width page, so the Sidecar takes the screen instead of squeezing the record into a column that cannot hold it. The thread, the context and the controls are unchanged.

The conversation moves to the Workspace

Open in Workspace carries the saved conversation's own id. The Workspace does not receive a copy of the messages from the browser — it reopens the conversation from the database, re-authorized for whoever is reading now, which is the same path any saved conversation takes.

This pair is a live capture, not a replay: a saved conversation id exists only in live mode, so replay could not show it. The run was planned and worded by google:gemini-3.5-flash-lite against the local estate on 2026-09-23, and the result was COMPLETE.

• checking a business object
• resolving an enterprise identity
• reading a downstream system
• retrieving a document
• running a calculation

Agent activity reflects execution state. It is not chain-of-thought.

The answer itself arrives whole once the governed run finishes. V1 does not manufacture token-by-token streaming: there is nothing to stream until the runtime has finished deciding what may be said.

The model chooses meaning. Twindexers chooses presentation.

EKA never asks a model for a layout, for markup, for component names or for visual hierarchy. The runtime returns a typed answer, and a deterministic adapter turns that into view models the design system renders.

EkaAnswer · typed evidence · feature resolutions · calculations · result status
        ↓
deterministic UI adapter
        ↓
Twindexers view models
        ↓
genui-ds components

The second group is a rule rather than a preference: inferring a journey by reading the answer's prose would make a structural claim out of a sentence, which is exactly the confusion the structure exists to prevent.

A step can be empty inside a complete answer

Show Kestrel's open invoices and total their open amount. The query was valid, permitted and executed, and it matched nothing. Nothing matched names the predicate that found none — and the request as a whole is COMPLETE, because the question was answered. The answer is that there are none.

Resolving a name is not finding the record

Show me the account for the customer named Kestrel. One organization resolved. Which CRM account was meant did not.

Resolving the customer does not erase ambiguity in the requested source record.

• conversations
• messages
• runs
• run evidence
• result sets
• task threads

Every value-bearing row carries the classification of the evidence it was produced from, and the read that fetches it applies the reader's current access in the same statement. So a saved answer that rested on a restricted document is not fetched and then hidden — it is not returned.

The whole sequence — asked at RESTRICTED + HR + PAYROLL, reopened at INTERNAL, then opened by a different principal who is simply told it is not available — is the 1 min 09 s recording in chapter 10 of the EKA Guide.

A phone frame is a layout exhibit and not an evidence exhibit: at 390 the composer cuts the lower evidence rows, so an evidence frame at that width shows the layout honestly and the evidence badly. The Sidecar overlay above is the same distinction from the other side.

User question
        ↓
optional page context
        ↓
─────────── trusted server boundary ───────────
        ↓
reference resolution
        ↓
feature / authority resolution
        ↓
validated plan
        ↓
governed tools
        ↓
access-aware enterprise reads
        ↓
typed evidence
        ↓
deterministic calculations
        ↓
grounded synthesis
        ↓
EkaAnswer
        ↓
deterministic UI adapter
        ↓
Workspace / Sidecar

Everything between the two ends is the runtime's: which subjects exist, which features are available on them, which tools may be called, which rows the reader may see, which arithmetic is performed, and what the result state is. The model proposes a plan; the validator is authoritative and may refuse it.

page context  →  reference hint  →  server resolution  →  access check
              →  governed read  →  evidence

The server does not trust a record because a browser said it was on screen. It resolves the reference itself, checks the reader's access to it, and reads it through the same governed path any other question would take. A field that happens to be rendered on the page did not thereby become evidence.

The interface must not imply that everything visible on the page became evidence for the answer.

EKA grounds ORG-000012
        ↓
UI presentation read, same viewer
        ↓
a fuller Organization card

Presentation enrichment can make a grounded object easier to read. It does not retroactively become evidence used to reach the answer.

So nothing a presentation read returns is shown as something the agent used, and a structured part — a journey, a resolution — renders only from structured evidence for that turn.

Why the difference is load-bearing

A step can run, succeed and find nothing — and one that does is exactly how EKA establishes an absence. Reading the activity list as support would turn we looked and there was nothing into we found something.

The three components this experience needed — RecordCard, StepTrace and MessageTurn — were specified back to genui-ds and released there rather than copied into this app, so the design system stays the one place the visual language lives.

┌─────────────────────────────────────────────┐
│ Browser                                     │
│   Workspace / Sidecar                       │
│   assistant-ui interaction                  │
│   genui-ds presentation                     │
└───────────────────┬─────────────────────────┘
                    ▼
┌─────────────────────────────────────────────┐
│ Next.js trusted server boundary             │
│   viewer resolution                         │
│   conversation persistence                  │
│   model policy                              │
│   request / response adaptation             │
└───────────────────┬─────────────────────────┘
                    ▼
┌─────────────────────────────────────────────┐
│ EKA runtime                                 │
│   interpretation · planning                 │
│   Queryable Subject Registry                │
│   governed tools                            │
│   evidence normalization                    │
│   deterministic calculations                │
│   grounded synthesis                        │
└──────┬───────────┬────────────┬─────────────┘
       ▼           ▼            ▼
  Canonical     Source      Documents
   records      systems    / retrieval
       └───────────┴────────────┘
                   ▼
               Evidence
                   ▼
               EkaAnswer
                   ▼
        deterministic adapter
                   ▼
       structured Agent Experience

the browser cannot assert a principal
        ↓
the server resolves a trusted viewer
        ↓
access-aware reads
        ↓
permitted evidence only
        ↓
model synthesis

Material the viewer may not use is filtered by the governed read layer before it can become evidence, so the model is never asked to keep a secret it was told. A request that carries a principal identifier is refused rather than ignored, because an ignored field looks exactly like an honoured one.

The browser cannot switch to another enterprise principal by sending a principal identifier.

A development-only View as control exists, and it accepts only the governed allowlist of real principals. Being the owner does not bypass authorization.

runEka
   │
   ├── read-only trace observer
   │        ↓
   │       server-sent events
   │        ↓
   │   live activity in the UI
   │
   └── completed EkaAnswer
            ↓
       final structured response

The observer is read-only. With no subscriber attached, EKA's semantics are identical.

That is what makes the activity rail safe to show: it cannot change the run it is describing, so nothing about an answer depends on whether anyone was watching it being produced.

Agent Experience  →  model policy  →  provider adapter  →  qualified model

• the browser may select only an allowed policy, and a policy is chosen per conversation
• provider credentials stay server-side
• every run records the model that actually answered, which under a fallback is not always the one asked for

A model is not supported because its API responds. It is eligible once it passes the smoke and golden qualification the release policy requires.

That gate is switched on for release, and today no model has passed it — so the selector offers Auto and nothing else, and an unqualified model produces an explicit retryable failure rather than a degraded answer.

runtime output  →  EkaAnswer  →  UI adapter  →  view model  →  genui-ds components

The adapter is deterministic and shared: the same function turns a captured run into a view model for a test fixture, a replay and a live turn, which is what makes a golden run usable as a UI regression test at all.

What it may not do

Do not infer a journey, a resolution or a timeline by parsing an answer's prose.

A structured part renders from structured evidence for that turn, or it does not render.

• no business mutations
• no external web evidence
• no implicit currency conversion
• no model-authored SQL
• no effective-policy-at-time
• no personalization

The enterprise cases that test how EKA reasons are the same cases that test how the interface represents it.

a live EKA run
        ↓
an approved captured result
        ↓
an EkaAnswer fixture
        ↓
the deterministic UI adapter
        ↓
a UI view-model fixture
        ↓
Workspace and Sidecar tests

Because the adapter is deterministic, a run that was promoted for its reasoning becomes a regression test for its presentation at no extra cost — and a change that quietly altered how a limitation or a result state renders fails against a real answer rather than against a hand-written one.

What the curated suite covers

• absence without an invented cause
• deterministic aggregation
• source and document authority together
• PARTIAL
• UNAVAILABLE
• a successful empty result
• cross-system operational links
• unsupported effective-time reasoning
• ambiguity preserved
• saved-conversation access re-gating

What a case asserts, and what it does not

A model proposes a structured plan, and the validator is authoritative. When it refuses one, the refusal goes back once, verbatim; a second refusal ends the turn as invalid, and every attempt is recorded. The validator is never weakened to make something answer.

The interface can show a completed run with its limitations rather than pretending every step succeeded on the first attempt.

• A replay capture re-runs a previously executed real run through the same adapter and renderers. No model is called during the replay — which is what the on-screen line “Model · scripted (captured run)” records.
• A live capture ran against the local estate at capture time, with the model the frame itself names.
• Nothing here was staged. No answer was written by hand, no transcript was composed after the fact, and no question was arranged to produce a flattering one. Where a run found nothing, refused, or could answer only part of what was asked, that is the run.

Not one build

The media spans more than one prompt bundle, and saying otherwise would be the easiest false claim on the page to make. The guide's own runs were captured under PROMPT-EKA-0.4.6; the eight GOLDEN captures were promoted under 0.4.4, and CUR-012 under 0.4.5. Each remains valid evidence for the case it was approved against.

The live EKA surface itself is not public. This page shows captures of it; the application is owner-only and a deployment that does not enable it serves no EKA route at all.

Finance, operations, HR, compliance and cross-system monitoring are all the same shape of problem: a governed runtime that knows what may be read, and an interface that does not hide the structure underneath the answer.

The goal is not to make enterprise software look like chat. It is to make enterprise reasoning conversational without hiding the enterprise underneath the answer.