The AI Consultant Button: Unified Interface Architecture

Fractera prioritizes interactive data conversation as a core system feature. Traditional enterprise portals are inherently inefficient. They force users to navigate sprawling, multi-layered menus and wait for heavy page components to render just to locate a single data point or execute a routine update.

Legacy interface complexity forces developers and end-users to study application structures deeply just to move data through step-by-step transaction pipelines. This design bottleneck introduces unnecessary operational drag. Our architecture removes this complexity by handling user actions through direct intent validation.

The interface protocol detailed below simplifies user discovery across public, authenticated, and administrative layers. The objective is to restructure workspace navigation into a single input stream:

• Direct Layout Discovery: Anonymous visitors enter a route and query the system in natural language to locate relevant pages and indexing nodes immediately.
• View Component Control: Users adjust theme settings, toggle layout readability states, or update localized interface languages entirely through input intents.
• Authenticated Account Queries: Logged-in users query system records directly, pull invoice histories, or draft and dispatch transaction requests to backend targets.
• Administrative Architecture Mutations: Project administrators execute natural language commands to declare new backend services, spawning real-time workspace pages and tools.

This specification focuses on the underlying integration layer—detailing how communication remains secured, sandboxed, and optimized across your local database configurations and Redis cache layers.

Infrastructure Execution: Server vs. Client Boundaries

The platform ships with a minimal-but-sufficient client widget that connects to your infrastructure endpoints immediately following deployment. This layout enables basic view-layer manipulation out of the box.

System isolation relies on a strict execution rule: the intelligence layer runs on the server, while action deployment is handled by the browser. The server evaluates available tool schemas, references configuration states, and suggests layout mutations—but it cannot manipulate an open browser tab directly. Specific view configurations (language states, layout themes, navigation paths) execute inside the browser client, enabling immediate view updates without full page reloads.

To maintain this boundary, a server-side routine updating a global configuration file changes only the on-disk repository baseline. Already-open browser tabs remain isolated because the server lacks a direct handle to active web views, and the client manages its layout state using local storage structures.

Hierarchical Access Tiering

System security is enforced by nesting individual tool capabilities within three strict access groups: `public ⊆ user ⊆ owner`. Access levels are determined server-side from the session state and are never validated based on client-side requests.

• public: Guest access requiring no active session. Operations are restricted to local view-layer configurations, indexing queries, and page navigation.
• user: Authenticated customer sessions. Grants access to isolated personal records, transaction logs, and profile mutations linked to their specific identity.
• owner: System administrator. Grants full permissions to modify shared configuration states, update global defaults, and execute repository code generation.

The following script illustrates how the endpoint determines access rights by reading server-side session cookies:

// lib/consultant/tier.ts (Architectural Overview)
async function resolveTier(req) {
  const session = await getSession(req)      // Read validated authentication session
  if (!session) return 'public'              // Anonymous guest baseline
  if (session.roles.includes('architect')) return 'owner'
  return 'user'                              // Authenticated standard account
}

The Client Widget Entry Point

The interface is mounted globally as a fixed, non-intrusive container in the viewport. The widget checks connection paths prior to rendering—if the background server daemon is offline, the interface element remains unrendered to prevent dead ui states.

// The widget audits background daemon availability prior to mounting
const { available, tier, keyConfigured } = await fetch('/api/consultant').then(r => r.json())
if (!available) return null                  // Daemon unreachable → suppress layout element
// Render active input node containing current verification context indicators

Client Execution: Deferred Action Envelopes

View mutations are structured as tools that the server suggests but the browser client executes. The server-side routing logic avoids direct file mutations, returning a light, deferred action payload that the client interface maps to native handlers.

// The server endpoint transmits a structured metadata block instead of direct code:
{ "__client_action__": true, "tool": "public_view_set_locale", "args": { "locale": "fr" } }

// The client engine routes incoming instructions through an absolute allowlist:
function runAction(action) {
  switch (action.tool) {
    case 'public_view_navigate_page': return router.push(action.args.to)
    case 'public_view_set_locale':    return router.replace(`/${action.args.locale}/...`)
    case 'public_view_set_theme':     return setTheme(action.args.mode)
    case 'public_view_set_width':     return setWidth(action.args.width)
  }
}

This division forms a strict client-side security boundary. The browser rejects unlisted commands out of the streaming payload, parsing arguments exclusively through clear validation rules. The user’s interaction with the generated action element serves as the confirmation trigger, eliminating intrusive verification modals.

Public Process Sandboxing

Public data access runs inside an isolated background process, completely decoupled from the administrative owner environment. Its tool definitions represent a minimal code subset that completely excludes administrative logic, preventing malicious access by omitting the underlying execution endpoints. A secondary environment restriction caps the process ceiling at the standard user level.

# Launch public-facing daemon under strict permission limits and isolated directory roots
HERMES_HOME=/root/.hermes-public  FRACTERA_AGENT_MAX_TIER=user  hermes dashboard --port 9129
# Configuration indexes restrict visibility strictly to public tool schemas

The daemon binds exclusively to local loopback ports. Incoming user requests pass through a shallow server-side endpoint that handles API token authentication securely, ensuring that anonymous traffic cannot exhaust developer keys or processing budgets.

Single Endpoint Turn Execution

The interface maps all communications to a single backend endpoint: `/api/consultant`. This routing node evaluates incoming session tokens, relays text data to the sandbox process, and returns a clean, structured payload containing layout copy and any deferred action schemas.

// POST /api/consultant  → Single data-driven turn execution
{
  "text": "System locales are restricted to EN, DE, and FR. Selected language is unmapped — choose alternative:",
  "actions": [
    { "tool": "public_view_set_locale", "args": { "locale": "fr" }, "label": "Français" },
    { "tool": "public_view_set_locale", "args": { "locale": "de" }, "label": "Deutsch" }
  ]
}

Authentication Escalation Protocols

When a user intent demands an access tier higher than the current session permission, the system blocks execution without throwing generic failures. The orchestrator determines the required security target and updates the interface with targeted instructions alongside an authorization link:

• Private Data Scopes: Requests targeting specific user databases trigger a prompt to authenticate. Once logged in, the updated user session opens the appropriate personal data tools.
• Role Capacity Restrictions: Requests that are outside the scope of standard accounts inform the user that the operation requires elevated developer permissions or administrative access.

Both events redirect users through standard authentication routes before returning them to their previous application state, allowing them to re-run the intent without losing execution context.

Expanding Capabilities via Natural Language

Expanding system capabilities is a built-in architecture feature. To register new tool sets or functional skills, developers use the administrative control view at [your-domain]/ai-draft-settings. This interface processes free-form descriptions to generate fresh MCP servers, assigning exact access levels (public, user, or owner) during the initial design phase. A specialized background agent evaluates the request and builds the tool into the workspace.

The draft layout captures all required operational configurations: the target security tier, whether the tool is read-only or mutates backend state, and a preview of its functional naming conventions, applying security schemas from the moment of creation.

If further customization is required, engineers drop into the platform’s integrated terminal environments or manage extensions via local development tools. The infrastructure ships with complete source code to support custom scaling requirements.

1. Infrastructure Provisioning: Deploy the core package to instantly mount a working layout containing the active input widget.
2. Intent Testing: Basic layout manipulation and page indexing lookups execute out of the box.
3. Capability Drafting: Define custom tool sets inside the configuration panel, assign their access tiers, and let the agent compile them.
4. Absolute Extension: Use the terminal or local text editors to modify core files. Your team retains full code ownership.

Functional Walkthrough: Locale Execution

1. The input container evaluates background connection states and renders the chat view upon user interaction.
2. The backend endpoint parses current session cookies, identifies a public permission rating, and hands the input to the sandbox daemon.
3. The daemon reads your project configuration files, checks available language definitions, and lists active locales.
4. The system maps matching action payloads to the available language parameters, returning a deferred action envelope.
5. The interface displays the resulting message block along with direct navigation options.
6. The user triggers the target language option; the client verifies the parameters against its rules and executes a clean client-side path change.

The entire sequence leverages native client-side routing. The backend infrastructure maintains data boundaries and suggests changes, while the browser engine executes the layout update.

Core Architecture Advantages

• Intent-Based Navigation: Users state explicit data goals, and background models locate the exact asset path, removing the need to memorize dense menu trees.
• Consolidated Interface Footprint: A single interface node hosts an expanding library of MCP tool connections, keeping visual layouts clean as backend complexity grows.
• Persistent Project Memory: LightRAG integrates graph-shaped long-term memory models directly into the workspace, ensuring the assistant’s context sharpens across tasks.
• Sovereign Source Isolation: The platform executes entirely on your own virtual hardware, eliminating dependencies on opaque third-party cloud providers.
• Isolated Security Baselines: Guest permissions cannot compromise administrative tool servers because the corresponding routes are physically absent from the public process.

Tool Capabilities mapped by Access Tier

The input widget responds strictly through capabilities explicitly defined within your project manifests. Available operations depend entirely on current session validation states. This list scales dynamically as new MCP tool servers are registered.

Public Scope (Anonymous Guest Access)

• Theme Control: Toggle application layouts between light, dark, or system preferences within the active viewport.
• Locale Modification: Update the current interface text to match any pre-compiled language file.
• Layout Constraints: Modify view widths between narrow or wide tracking boundaries to improve readability.
• Asset Navigation: Execute instant client-side jumps to specific internal paths like product lists or pricing pages.
• Surface Indexing: Query the local directory structure to identify public application sections.

User Scope (Authenticated Personal Account Access)

Following session validation, the engine exposes secure tools targeting your personal account database records, isolating queries from adjacent customer scopes. Attempting these actions from an anonymous state displays an authentication card. Enabled capabilities include: order tracking and transaction histories, invoice downloads, subscription state adjustments, and account log reviews.

Owner Scope (Administrative Infrastructure Access)

Authenticated system administrators manage global configuration vectors, adjust platform defaults, declare new endpoint routes, and compile custom tool chains inside the configuration panel. The public-facing process completely excludes these capabilities, redirecting unauthenticated requests to your secure login views.

• Register Architecture Tasks: Append fresh database records to your system layout dashboard to trace route changes or declare new endpoints. Handled by tool `owner_arch_create_record`.
• Consolidate Build Chains: Move pending development logs into active build steps inside your control dashboard, resetting temporary task records. Handled by tool `owner_arch_send_to_steps`.
• Generate New MCP Servers: Draft custom agent capabilities inside the configuration panel, establishing their target access tiers and compiling them into production. Handled by tool `owner_draft_send_to_steps`.
• Route Service Requests: Segment any "I want a service / tool / automation" wish into public product pages versus a private project level (automations, page management, personal services) before any pipeline runs; an ambiguous wish triggers one clarifying question and the route is only fixed after your explicit confirmation. Handled by tool `owner_projects_route_request`.
• Survey Automation Needs: Collect scheduled-job (cron) intents and external integration requirements for a private project as a simple checklist, normalizing each integration into the API environment keys the project will need. Handled by tool `owner_projects_survey_automation_needs`.
• Decompose a Project Before Building: Turn a confirmed private project into a validated graph of small nodes and materialize the WHOLE development queue to disk before any code — a project overview README (why / how it works / efficiency / reuse / result), one exhaustive specification step per node and one coder-handoff step per node; an incomplete specification is refused, you confirm the full order sheet first, and graphs over ten nodes receive an MVP recommendation. Handled by tool `owner_projects_orchestrate_decomposition`.
• Transfer External Documentation: Carry the documentation an automation depends on (an API reference, an SDK guide) from the internet onto your workspace disk and into Company Memory — with your agreement first — so coding agents, which usually have no internet access, find it locally; the document body never passes through the model, only its path, size and table of contents. Handled by tool `owner_docs_transfer_external_documentation`.

Knowledge Storage Boundaries

This reference document serves as a high-level overview of interface features. It targets basic system concepts and intentional security splits, keeping the technical copy lightweight.

For detailed architectural inspection, query your workspace’s LightRAG vector graph directory. This long-term memory layer is accessed by prompting the Hermes daemon within your secure administrative dashboard, allowing you to pull exact system blueprints and repository layout traces on demand.