| Firm | Owner | Members | Created | Status |
|---|
No firms yet
Add the first firm to provision its tenant.
| Captured | Firm | Architect | Scope | Insight |
|---|
No insights yet
Insights appear here when an architect flips a Frank prompt into account-level feedback.
Couldn't load insights
Tektura staff who can sign in to this console and the webapp's admin surface. Access is
the tektura_admin claim on the person's Descope account — not a firm
membership.
| Admin | Status | Added |
|---|
No admins found
Descope returned no user carrying the admin claim — which shouldn't be possible while you're signed in here. Check the Descope project's custom attributes.
Couldn't load admins
The executive read of the pricing program: how much of the catalogue is ready to price, where it's heading, and what's in the way. Composed from the same measurements as Cost Atlas, plus the Credits catalog's pricing basis for the recommendation. It reports; it never decides a price.
Couldn't load the overview
What one job of each product costs us to run, how solid that number is, and how far it has moved since we froze it. This surface reports measurements only — no prices.
Couldn't load cost data
Cost by capability and product
What one job of each product costs us, how far it has moved since we froze it, and how much to trust the number. Pick a capability card to filter the table; click a product's Why? for its cost basis and evidence. Grey figures rest on too few jobs to trust.
| Product | Measured per | Frozen cost | Live | Drift | Jobs | Evidence |
|---|
Every job, with its request
One row per commercial job — a contiguous run of turns on one outcome. A job above its product's ceiling is marked runaway; a job that did several products at once is excluded from per-product cost and marked as such.
| Request | Firm | Products | Opened by | Turns | Total |
|---|
Every cost above feeds the Credits tab, where a price is set once, with commercial judgment — never calculated straight from cost here.
Cost × time
What one job of each product costs us and how long it keeps the architect waiting — the two halves of a price, one row per measured product. Time comes from the Performance pipeline through the same task corrections, so both halves describe the same jobs. The per-unit columns divide by the planner-declared job size where one exists — a dash is undeclared, never zero.
| Product | Evidence | Cost / job | Wait / job | Typical size | Cost / unit | Wait / unit | Intensity |
|---|
What changed, and where to look next
Two dated reconstructions of the corpus, then four rankings of the same products — each ordered by a single stated criterion, never merged into one priority.
Document processing cost
What does reading in their drawings cost, and how solid is it?
Reading in each firm's drawings and documents — a background operation whose cost scales with one unit: the page.
How complete is this cost, and how much data is behind it?
Cost is summed per run, one page at a time. The bars below show how much of the recorded work carries a cost — a $0 run means nothing was recorded, not that the work was free.
Breakdown by firm, by project, and by document type
Per-firm and per-project processing cost, plus workload by document kind. The by-project view is the one place chat and processing cost meet for a single project.
Customer workload
| Document kind | Documents | Pages |
|---|
By firm
Processing only. A row whose work recorded no cost reads not captured — never $0.00 — and a partially captured figure carries a ≥ floor marker; hover a spend cell for the run-ledger and realtime split.
| Firm | Sheets | Documents | Pages | Items | Spend |
|---|
By project
Chat and processing together, grouped by firm. Click a firm row to collapse it.
| Firm | Project | Total | Chat | QA turns | Processing |
|---|
Fresh-data confirmation
A holdout check: we set aside the turns recorded after the frozen baseline, then re-run each cost driver against only those unseen turns. A driver counts as confirmed only if it reproduces there — an underpowered fresh window honestly answers "not yet".
| Product | Driver | Baseline | Status | Fresh turns | Effective n | Why |
|---|
Pricing history
Every snapshot the frozen costs have ever been committed to. A new Frank version can cost differently, so each snapshot is tied to a Frank build; nothing re-prices mid-stream, and old snapshots stay in the list.
| Task | Frozen | Live, same method | Drift | Jobs under newest Frank | Progress to re-baseline |
|---|
Proposed credit prices, derived from Cost Atlas's measured costs by a stated policy. Measured cost is a hard floor; click any product for the whole chain, cost basis upward. Every value is internal-only and proposed, never billed.
Loading the credits economy…
Couldn't load the credits economy
Commercial policy
How is each capability commercialized?
Why?
- The commercial decision never changes because of evidence alone. Evidence strength is shown separately, by Cost Atlas, and consumed here as an attribute of the row.
- Commercialized — we intentionally sell it. Included — deliberately free in the subscription, with the value we give away kept visible. Internal — not customer-purchasable. Awaiting policy — commercial policy not decided yet, evidence gathering. Opportunity — not live yet.
- A thin sample is a fact about the evidence, not the decision: a product we sell stays Commercialized whether its cost is measured over three jobs or forty. The Evidence column on each row carries that confidence signal.
The catalogue
What is each product worth?
Why?
- A price is the product's typical job cost (its average job cost with runaway jobs trimmed to the product's normal ceiling) divided by 1 − the target margin, rounded up to a whole credit, never below what the job costs us.
- Supporting operations are the exception: their margin already sits in the review that invokes them, so they are priced at cost coverage only.
- The evidence column is the Cost Atlas's own tier and job count, with a link across to it. Nothing here re-judges it.
| Product | Cost / job | Proposed | Quoted on → cost scales on | Packaging | Architect time saved (est.) | Evidence |
|---|
Usage by firm and member
Who is consuming credits, and how much?
Consumed credits per firm and per conversation owner over the selected scope — the same figure the customer's Plan meter shows, beside the cost and margin behind it. Credits mark measured cost up to the target margin at the catalog denomination; runaway turns are capped at the p99. Dollars and margin are operator-only.
By firm
| Firm | Credits used | Cost | Margin | Members | Unpriced |
|---|
By member
| Member | Credits used | Cost | Margin | Priced turns | Unpriced |
|---|
Price simulation
Would this price have covered its cost?
A flat per-job credit run against real Fire Rating Review jobs: each job's actual provider-reported cost next to the credits the scenario would have charged. Multi-task jobs are excluded, never allocated — splitting a shared job's cost across products is a decision that has not been made.
Simulated jobs (the per-job detail behind the tiles above)
| Request | Last turn | Actual cost | Implied credits | Cost / credit | Margin (hypothetical) |
|---|
Review-class leakage
Is work landing in the class we price it as?
Credit-worthy work escaping the meter: review-class work that carries no task label, since the labeling path went live. Question-class work is included in the subscription, so unlabelled question turns are fine — zero here is the healthy state. A turn is judged by the request class Frank declared for it; only turns with no declared class fall back to the cost floor.
Two separate things, never merged. Class state is a property of the turn: declared (the planner named a class), planner silent (capture was live and it named none — an open instrumentation bug worth fixing), or legacy (pre-capture, no declaration could ever have existed). Judged by is a property of the decision: the declaration, or the cost floor standing in for one. The floor spans planner-silent and legacy turns, so it is shown as a judgment source and never as a state that hides them.
| Request | Class state | Judged by | When | Cost |
|---|
Opportunity pipeline
What is not sold yet?
Declared capabilities with no commercial value today. Each says what is actually in the way — Frank does not author the artifact yet, or nothing can label the work, so no evidence can ever accrue against it. These are the entries that would enter the funnel at Commercial Declaration.
| Capability | What is in the way | Evidence |
|---|
Every cost figure behind a price here is measured on the Cost Atlas, and so is every evidence rating: this tab consumes both and re-derives neither. Open the Atlas for the sample, the ceiling, the trimmed jobs and how far one more job could move a number.
What we spend on AI across providers, and — when it moves — whether it's volume, mix, or unit cost driving it. Live measurements; a gap means unknown, never zero.
Couldn't load the cost monitor
How long Frank keeps architects waiting — tracked per task and across Frank versions. Every time below is customer wait: the clock from the architect pressing send to the answer appearing.
Couldn't load performance data
Customer wait wall-clock
How long the architect waited for Frank to finish, start to end. This is the headline for every time shown here.
Per unit
Wait divided by the size of the work — doors, sheets, sqft — so a big job and a small one compare fairly. Needs declared scope.
Model intensity
How much AI compute ran versus the wait. 2× means about two AI workers ran in parallel. It is not part of the wait.
Is Frank getting faster?
One task at a time — different tasks are different work and never share an axis. Pick a task; the line is its median wait per job at each Frank version.
Which tasks are slow?
Slowest first. Read each row on its own — the bar ranks raw job time for triage, but tasks do different work, so the per-unit column is the honest comparison once scope was declared.
Customer wait per reply (SLA)
Per single reply, not per job. Median is the typical wait; p95 is the slow end (19 in 20 are faster). The gap between them is what to read: a long bar means replies vary a lot — often because some jobs are simply bigger (more doors / sheets) than others, not because Frank is erratic. To separate size from speed, use the per-unit view above.