Skip to content
SCOPERAILA FOKALABS PRODUCT

AI BUILT INTO THE TOOLS PEOPLE ALREADY USE

Useful AI, where work already happens.

Your teams know what to do. Your customers keep moving.

ScopeRail connects the knowledge, systems and operating rules your company already relies on. People find the right answer, move a task forward or hand off a clear request without changing tools. You keep control of access and decisions.

First built for Sextan, a complex operations product where each role sees and does something different.

A question is matched with identity, screen, knowledge and live data. ScopeRail selects the allowed tools, prepares a next step and waits for human confirmation.

01 / SEE THE WORK MOVE

One question becomes useful progress.

These are fictional examples. The interface changes with the business, while the rail stays familiar: understand the situation, consult the right sources, prepare the next step and keep the person in control.

01 / OPERATIONS / INVENTORY

The team can answer from the stock already on screen.

A sales coordinator is looking at one product record. The answer depends on available, reserved and incoming stock.

02 / FINANCE / PERFORMANCE

Finance gets the number with its perimeter attached.

A finance lead asks from a reporting screen. The useful answer needs the same activity, region and accounting definition as the open view.

03 / SUPPORT / TICKET

A vague message becomes a ticket someone can act on.

A customer reports a payment problem from the settings screen. ScopeRail can see the product context, but it still asks for what the ticket needs.

SCOPERAIL / AGENT THREAD 01LIVE
YOU

Can we commit 120 units of MX-42 to the Lyon site this week?

SR
SCOPERAILSCREEN CONTEXT SELECTED
USED

I’m using the open MX-42 stock view because it matches the item and site in your question.

CURRENT SCREENMX-42 / Stock positionLIVE
Available
148
Reserved
40
Inbound
96 · Thursday
Site / LyonItem / MX-42Role / Sales operations
AGENT ACTIVITY02 / 02
01SOURCEAllocation and commitment rulesCurrent warehouse policy · approved operating ruleUSED
02LIVE TOOLread_inventory_position108 unreserved now · 96 expected ThursdayCOMPLETED
SR
SCOPERAIL

You can commit 108 units now. The remaining 12 depend on Thursday’s receipt. I can prepare a split allocation that keeps the promise explicit.

ACTION PROPOSEDCreate a split allocation
YOUR CONFIRMATION

Commit what is available now and keep the remaining promise tied to Thursday’s receipt.

NOW
108 units
THURSDAY
12 units
DESTINATION
Lyon
Edit quantitiesRejectConfirm allocation

Not executed. Nothing changes until you confirm.Review quantities and dates. The allocation is created only after confirmation.

01 / OPERATIONS / INVENTORY

The team can answer from the stock already on screen.

A sales coordinator is looking at one product record. The answer depends on available, reserved and incoming stock.

SCOPERAIL / AGENT THREAD 01LIVE
YOU

Can we commit 120 units of MX-42 to the Lyon site this week?

SR
SCOPERAILSCREEN CONTEXT SELECTED
USED

I’m using the open MX-42 stock view because it matches the item and site in your question.

CURRENT SCREENMX-42 / Stock positionLIVE
Available
148
Reserved
40
Inbound
96 · Thursday
Site / LyonItem / MX-42Role / Sales operations
AGENT ACTIVITY02 / 02
01SOURCEAllocation and commitment rulesCurrent warehouse policy · approved operating ruleUSED
02LIVE TOOLread_inventory_position108 unreserved now · 96 expected ThursdayCOMPLETED
SR
SCOPERAIL

You can commit 108 units now. The remaining 12 depend on Thursday’s receipt. I can prepare a split allocation that keeps the promise explicit.

ACTION PROPOSEDCreate a split allocation
YOUR CONFIRMATION

Commit what is available now and keep the remaining promise tied to Thursday’s receipt.

NOW
108 units
THURSDAY
12 units
DESTINATION
Lyon
Edit quantitiesRejectConfirm allocation

Not executed. Nothing changes until you confirm.Review quantities and dates. The allocation is created only after confirmation.

02 / FINANCE / PERFORMANCE

Finance gets the number with its perimeter attached.

A finance lead asks from a reporting screen. The useful answer needs the same activity, region and accounting definition as the open view.

SCOPERAIL / AGENT THREAD 02LIVE
YOU

What was revenue from maintenance contracts in the South region last quarter?

SR
SCOPERAILSCREEN CONTEXT SELECTED
USED

I’m using the open Q2 report. It already carries the South and Maintenance filters.

DEMO DATA / CURRENT VIEWRevenue / Q2FILTERED
Region
South
Activity
Maintenance
Currency
EUR
Entity / AtlasPeriod / Q2Role / Finance lead
AGENT ACTIVITY02 / 02
01SOURCERevenue recognition definitionBooked revenue · tax excluded · closed periods onlyUSED
02LIVE TOOLquery_revenue_summary€1.84m booked · 96 invoices in the selected perimeterCOMPLETED
SR
SCOPERAIL

Booked revenue is €1.84m for the selected period, region and activity. The accounting definition and filters stay attached so the result can be checked.

ACTION PROPOSEDExport this scoped result
YOUR CONFIRMATION

Keep the accounting definition and the active filters attached to the export.

RESULT
€1.84m
RECORDS
96 invoices
SCOPE
South · Maintenance
Edit filtersCancelConfirm export

Not executed. Nothing changes until you confirm.Review the perimeter. The export is generated only after confirmation.

03 / SUPPORT / TICKET

A vague message becomes a ticket someone can act on.

A customer reports a payment problem from the settings screen. ScopeRail can see the product context, but it still asks for what the ticket needs.

SCOPERAIL / AGENT THREAD 03LIVE
YOU

Payments still fail for our German customers. Can you fix it?

SR
SCOPERAILSCREEN CONTEXT SELECTED
USED

I’m using the open payment settings. They identify the account, market and production mode.

CURRENT SCREENCheckout / Payment settingsACCOUNT VIEW
Provider
Adyen
Market
Germany
Mode
Production
Account / NorthstarRegion / EURole / Admin
AGENT ACTIVITY02 / 02
01SOURCEPayment incident intakeRequired evidence and routing for checkout incidentsUSED
02LIVE TOOLread_recent_payment_errors3DS timeout pattern · Germany · first seen at 09:42COMPLETED
SR
SCOPERAIL

I can prepare the incident ticket. Two details are still missing:

  1. 01Does every card fail, or only cards using 3DS?
  2. 02May I attach the last three failed attempts?
ACTION PROPOSEDCreate a payment incident
YOUR CONFIRMATION

Route a qualified ticket with the product context and the evidence the customer approves.

MARKET
Germany
SIGNAL
3DS timeout
EVIDENCE
3 attempts
Edit ticketRejectConfirm creation

Not executed. Nothing changes until you confirm.Review the scope and evidence. The ticket is created only after confirmation.

02 / ONE SYSTEM. FAMILIAR WORK.

Help people understand, move and hand off.

A job site, a workshop, an accounting office or a software product: the work changes, but the need does not. Bring company knowledge and live information to the right person, inside the tool already open.

  1. ON SITE

    Find the right procedure.

    A field team gets the instruction that fits this site, this role and the situation in front of them.

  2. IN OPERATIONS

    Move the case forward.

    A back-office or workshop team checks the current state, understands an exception and prepares the next valid step.

  3. IN THE PRODUCT

    Help the user in context.

    A customer gets an answer that fits the screen, account and access they already have.

  4. AT HANDOFF

    Create a useful request.

    A vague question becomes a complete ticket with the context, evidence and expected outcome attached.

03 / THE CONTEXT GAP

The answer is rarely in one document.

The same question can mean something different for another person, screen or account. ScopeRail checks the situation before it asks a model to answer.

DOCUMENT CHAT

A document assistant can explain what is written. It cannot know what is happening now, which record is open or what this person is allowed to see and change.

SCOPERAIL

ScopeRail starts with the signed-in user and current product state. It gathers only the useful knowledge and tools, then returns an answer or next step that fits the moment.

  1. Identity
  2. Current screen
  3. Knowledge
  4. Live state
  5. Allowed tools
Five sources of context converging into one controlled ScopeRail route.

04 / ONE QUESTION. THE RIGHT SCOPE.

The context changes. The useful answer changes with it.

Choose a role. The graph shows what can be read, what stays outside the boundary and whether a next step can be prepared. Product permissions remain the authority.

QUESTION / 01Why is this request blocked, and what can I do next?

ScopeRail control graph from identity and product context to evidence, a proposed action and a human checkpoint.
  1. Identityavailable
  2. Screenavailable
  3. Scopeavailable
  4. Knowledgeavailable
  5. Live toolsout of scope
  6. Evidenceavailable
  7. Proposed actionout of scope
  8. Human checkhuman check

Customer

The request is waiting for an internal review. You can see its status and the information already shared with you. Approval is not available from this account.

No write action is proposed for this role.

Read all three scenarios
  • Customer: The request is waiting for an internal review. You can see its status and the information already shared with you. Approval is not available from this account. Open request status.
  • Operator: One required document is missing. You can prepare a complete review ticket with the current record, the relevant procedure and the missing item. Prepare review ticket.
  • Admin: The request is complete and ready for an authorised review. The applied rule, current record and activity trace are available before approval. Review the proposed approval.

05 / BUILT IN A REAL PRODUCT

From a product question to a precise, controlled next step.

ScopeRail began inside Sextan, a complex operations product. The assistant sees the current module, checks the server-side access boundary, searches the permitted sources and uses approved tools before it answers.

PUBLIC LOOP

  1. 01Situate
  2. 02Search
  3. 03Propose
  4. 04Confirm
  5. 05Act
  6. 06Review
An anonymised ScopeRail execution trace showing validated context, evidence, a proposed ticket and a human checkpoint.
USER QUESTIONThis request is blocked. What is missing?
VALIDATED CONTEXT
  • Role / operator
  • Module / requests
  • Scope / current site
EVIDENCE USED
  • Relevant procedure
  • Live request state
  • Permission policy
PREPARED OUTCOMEOne missing document is identified. A review ticket is ready with the record, source and expected next step.

User confirms before the ticket is created.

01Situate the request

The current route and module arrive as hints. The host product validates them against the signed-in user and active scope before they can influence the answer.

02Search inside the boundary

Lexical and semantic retrieval search only the knowledge this user can access. Restricted material never needs to enter the model context.

03Check live state

Approved read tools inspect the current record. The active module keeps the tool list relevant and the host application keeps every query scoped.

04Prepare, confirm, trace

The assistant can prepare a ticket or supported action. The person reviews it, the product checks access again, and the result leaves a trace.

06 / ONE SYSTEM. THREE SURFACES.

For your customers. Across your operations. Under your brand.

01 / FOR CUSTOMERS

Customer-facing assistant

Answer inside a product, portal or service journey with the current account, situation and available next steps already in scope.

02 / FOR TEAMS

Operations copilot

Help staff investigate exceptions, prepare work and move between systems without hiding the source or the decision.

03 / FOR PRODUCTS AND SERVICES

White-label capability

Use your name, interface, vocabulary and escalation path. ScopeRail stays behind the experience, whether the surface is new or already in place.

07 / START WITH ONE REAL WORKFLOW

Move fast on a boundary you can see.

We choose one frequent, costly or frustrating workflow. We connect the minimum useful context, test it with real questions and extend only what works in practice.

  1. 01Frame

    Name the user, the outcome, the available evidence and the line the system must not cross.

  2. 02Connect

    Link identity, knowledge, live product state and the few tools needed for this workflow.

  3. 03Evaluate

    Test real questions, access boundaries, weak evidence, tool errors and recovery paths.

  4. 04Operate

    Observe use, improve weak routes and add the next workflow only when the first one holds up.

Scope a production workflow

08 / SPEED WITH CONTROL

Move faster without giving the model the keys.

ScopeRail works through the identity, access rules and action handlers your software already uses. The model can suggest. The product remains in charge.

  1. 01The host product resolves identity and access.
  2. 02Browser context is checked on the server.
  3. 03Restricted knowledge is filtered before generation.
  4. 04Live tools remain scoped to the active account and role.
  5. 05The current workflow reduces the available toolset.
  6. 06Important actions wait for an explicit confirmation.
  7. 07Empty, denied, partial and failed remain distinct outcomes.
A controlled route with an orange decision point, a human checkpoint and a visible recovery rail.

Control is not one approval button. It is the ability to understand what happened, recover from an exception and change a model or provider without rebuilding the workflow.

10 / PRACTICAL QUESTIONS

What a first ScopeRail workflow actually needs.

Do we need to clean up all our documentation first?

No. We start with the sources required by one workflow, identify obvious gaps and keep the source material authoritative. The first slice should not depend on a company-wide documentation project.

What does a first integration include?

One user group, one workflow, its knowledge, live state, access boundary, useful tools, evaluation set and recovery path. The goal is a production slice that can be observed and improved.

Can ScopeRail work with older business software?

Often, yes. A modern front end is not required. What matters is a reliable way to resolve identity, read the necessary state and expose supported actions through an API, CLI, MCP server or a small adapter.

Do we need an API, MCP server or special connectors?

Not one universal format. ScopeRail can work with typed APIs, command-line tools or MCP. We choose the smallest interface that is secure, testable and maintainable for the workflow.

Can the same system serve employees and customers?

Yes. They can share the same context and action infrastructure. Each surface still receives its own identity, vocabulary, tools and boundaries.

How are permissions applied?

The host product remains authoritative. It resolves the signed-in user, filters knowledge and data before generation, and checks access again when an action is confirmed.

Can it create a ticket or prepare an action?

Yes, when a supported handler exists. ScopeRail can collect missing context and produce an editable proposal. The user confirms before the product executes it.

Can the assistant act without confirmation?

Only for actions the product team has explicitly classified as low risk and reversible. Important or ambiguous actions keep a human checkpoint.

How do you choose the model and hosting setup?

From the workflow, data sensitivity, latency, quality and operating constraints. We prefer the smallest model and simplest deployment that pass the agreed evaluation.

How do you know a workflow is ready?

It must pass representative questions, access tests, tool errors, missing evidence and recovery cases. A good demo is not enough. The exceptions need to work too.

SCOPE / INTAKE 01

Start with one
useful workflow.

Tell us who needs help and where work slows down today. We will map one useful workflow, its context and the smallest production slice.

01 / Identity

Or write directly to [email protected]