01 / Boundary
Does restricted context stay out?
Permission fixtures, cross-scope cases and host-side rejection of unauthorized writes.
Move fast. Keep the boundary explicit.
Practice first. Automate second.
ScopeRail starts with work people already do: answering a customer, finding the right procedure, preparing an intervention or turning a request into a clear next step. Knowledge, business data and tools then work together inside the rights already in place.
This is a portable operating method. It is not a release of customer code, private configuration or the Sextan implementation.
01 / THE CONTROL ROUTE
The model is one component. The boundary is the system.
Each stage has a narrow responsibility. Deterministic controls decide what is eligible. Models help select, interpret and propose inside that perimeter.
01
Hard policy
Resolve identity, scope, forbidden operations and confirmation rules outside the model. A prompt never grants access.
Host product remains authoritative02
Eligible catalogue
Build the available tool set after policy checks. The model sees only the tools this user and workflow may call.
Retain, narrow or deny03
Selection
Retrieve useful context and rank candidate tools for the task at hand. Ranking can improve relevance. It cannot widen eligibility.
Relevance never overrides policy04
Provenance
Carry source, version, freshness and access state into the answer. Missing, unavailable and denied remain different outcomes.
Evidence travels with the claim05
Propose or execute
Answer directly when the evidence is enough. For a write, prepare an editable proposal and let the host recheck authorization before execution.
Consequential writes need a checkpoint06
Trace and recover
Record the outcome, evidence references and tool result. If context is weak or execution fails, preserve a clear human recovery path.
Failure stays visible and recoverable
02 / PRACTICE BEFORE SCALE
Speed is a scope decision.
Fast teams do not expose every source and tool at once. They choose one recurring point of friction, run it end to end, inspect the exceptions and widen only what works.
- 01
Frame
Name the user, the decision, the useful evidence and the line the system must not cross.
- 02
Instrument
Collect representative questions, access cases, tool failures and the outcomes people actually need.
- 03
Ship a narrow slice
Put one complete workflow in real use behind the product's existing controls. A broad demo is not the goal.
- 04
Operate
Review weak answers, missing sources, denied actions and human escalations. Improve the route before adding another one.
Execution matters. Control keeps execution useful after the first demo.
03 / RIGHT-SIZED INTELLIGENCE
Use only the intelligence the workflow needs.
Responsible operation starts before model choice. Remove unnecessary calls, context and tools first. Then compare the smallest capable options on the same evaluation set.
- 01
Deterministic first
Use rules, lookups and typed validation when the answer is already explicit. Do not call a model to rediscover a known constraint.
- 02
Retrieve selectively
Bring in the sources required by the current question. More context is not automatically better context.
- 03
Pass the matrix
Choose the smallest model that passes the workflow's quality, access, tool and recovery evaluations. Size is not the acceptance criterion.
- 04
Escalate deliberately
Use a stronger model or a human only where the measured failure case justifies it. Keep the common path simple.
- 05
Measure real operation
Track useful outcomes, failed routes, latency and resource use. Optimise from observed work rather than benchmark theatre.
04 / EVALUATION GATE
The exceptions decide whether the workflow is ready.
There is no universal score for a controlled assistant. Each integration defines representative cases and explicit evidence for the decisions it must support.
02 / Evidence
Can the answer be traced to current, allowed sources?
Representative questions, retrieval holdouts, paraphrases and missing-source cases.
03 / Tool routing
Is the right eligible tool selected and called correctly?
Routing fixtures, invalid arguments, large catalogues and executable tool-chain tests.
04 / Action integrity
Are proposed, confirmed and completed kept distinct?
Confirmation, idempotency, cancellation, authorization recheck and partial-failure cases.
05 / Recovery
Does failure return control to a person?
Empty, denied, timeout, malformed result and fault-injection scenarios.
06 / Operational fit
Is this the simplest system that passes?
Compare no-model, smaller-model and larger-model paths on the same cases and constraints.
Thresholds, owners and release gates belong to the integration. The public matrix deliberately invents none.
05 / PUBLIC ARTIFACTS
Portable shapes for the hard parts.
These schemas and checklists make decisions reviewable across product, engineering, security and operations. Adapt and version them with the host system.
01Tool definitionJSON SCHEMADescribe purpose, eligibility, inputs, outputs, side effects and confirmation before a tool enters a catalogue.Open ↗02Pending actionJSON SCHEMAKeep a proposed write separate from confirmation, execution and outcome.Open ↗03Evidence envelopeJSON SCHEMACarry source identity, freshness, access state and limitations with a response.Open ↗04Ticket proposalJSON SCHEMATurn a vague report into a reviewable draft without submitting it on the user's behalf.Open ↗05Integration checklistMARKDOWNFrame identity, sources, tools, actions, evaluation and operation for one production slice.Open ↗06Evaluation matrixMARKDOWNDefine cases, evidence, owners and release decisions before choosing a model.Open ↗07Logging and redactionMARKDOWNObserve the route without turning prompts, tool results or personal data into telemetry.Open ↗08Threat modelMARKDOWNReview trust boundaries, injection, confused-deputy risks, excessive agency and recovery.Open ↗
Starting points, not certifications. Review them against your product, contracts and risk model.
06 / EVIDENCE MAP
Standards, research and field practice are not interchangeable.
The method uses each source for what it can support. Standards frame risk and interfaces. Research tests specific hypotheses. Field practice contributes useful operating patterns.
Standards and official documentation
Normative frameworks and maintained specifications. They guide controls but do not certify an implementation.
- Artificial Intelligence Risk Management Framework 1.0NIST · 2023Open source: Artificial Intelligence Risk Management Framework 1.0
- Model Context Protocol specificationMCP maintainers · 2025-11-25Open source: Model Context Protocol specification
- MCP Security Best PracticesMCP maintainers · 2026Open source: MCP Security Best Practices
- Syntax for GitHub Issue FormsGitHub Docs · 2026Open source: Syntax for GitHub Issue Forms
- Adversarial Machine Learning: A Taxonomy and TerminologyNIST · 2025Open source: Adversarial Machine Learning: A Taxonomy and Terminology
- OWASP Top 10 for LLM Applications 2025OWASP · 2025Open source: OWASP Top 10 for LLM Applications 2025
- Energy and AIInternational Energy Agency · 2025Open source: Energy and AI
Research
Peer-reviewed or research publications. Results remain bounded by their datasets, tasks and experimental conditions.
- Guidelines for Human-AI InteractionAmershi et al., Microsoft Research · 2019Open source: Guidelines for Human-AI Interaction
- Retrieval-Augmented Generation for Knowledge-Intensive NLP TasksLewis et al. · 2020Open source: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
- ReAct: Synergizing Reasoning and Acting in Language ModelsYao et al. · 2023Open source: ReAct: Synergizing Reasoning and Acting in Language Models
- τ-bench: Tool-Agent-User Interaction in Real-World DomainsYao et al. · 2025Open source: τ-bench: Tool-Agent-User Interaction in Real-World Domains
- AgentDojo: A Dynamic Environment to Evaluate Prompt Injection AttacksDebenedetti et al. · 2025Open source: AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks
- What Makes a Good Bug Report?Bettenburg et al. · 2008Open source: What Makes a Good Bug Report?
- Information needs in bug reports for web applicationsJournal of Systems and Software · 2025Open source: Information needs in bug reports for web applications
- The Probabilistic Relevance Framework: BM25 and BeyondRobertson and Zaragoza · 2009Open source: The Probabilistic Relevance Framework: BM25 and Beyond
- ColBERTv2: Effective and Efficient Retrieval via Lightweight Late InteractionSanthanam et al. · 2022Open source: ColBERTv2: Effective and Efficient Retrieval via Lightweight Late Interaction
- RAGAS: Automated Evaluation of Retrieval Augmented GenerationEs et al. · 2024Open source: RAGAS: Automated Evaluation of Retrieval Augmented Generation
- Toolformer: Language Models Can Teach Themselves to Use ToolsSchick et al. · 2023Open source: Toolformer: Language Models Can Teach Themselves to Use Tools
- ToolLLM: Facilitating Large Language Models to Master 16000+ APIsQin et al. · 2023Open source: ToolLLM: Facilitating Large Language Models to Master 16000+ APIs
- ToolRet: Tool Retrieval for Large Language ModelsACL Findings · 2025Open source: ToolRet: Tool Retrieval for Large Language Models
- ToolRerank: Adaptive and Hierarchy-Aware Reranking for Tool RetrievalLREC-COLING · 2024Open source: ToolRerank: Adaptive and Hierarchy-Aware Reranking for Tool Retrieval
Field practice
Useful engineering and product references. They are experience and direction, not scientific proof.
- Owning the Workflow in B2B AI AppsAndreessen Horowitz · 2025Open source: Owning the Workflow in B2B AI Apps
- Software Is Changing (Again)Andrej Karpathy · 2025Open source: Software Is Changing (Again)
- QMD: query Markdown with hybrid searchTobi Lütke · 2026Open source: QMD: query Markdown with hybrid search
- gstackGarry Tan · 2026Open source: gstack
SCOPE / DISCLOSURE
The method is public. Customer systems are not.
This publication describes portable interfaces, checks and operating choices. It does not expose customer data, prompts, credentials, private thresholds, internal configuration, source code or the Sextan implementation.