SC LABS / OPEN-SOURCE PROOF OF CONCEPT / ALPHA.2

SC NODE — SC LABS open-source runtime proof of concept

The runtime proof
that came before ARKTOR Core.

SC NODE remains the public Rust proof of concept that controlled routing, tools, permissions and audit can coexist with near-direct model performance. It marks where that direction became real in public code and still stands on its own as an open-source reference.

Version 0.1.0-alpha.2 is verified on Windows and Linux. Ollama and NVIDIA NIM are live-tested; OpenRouter catalog and schema handling are verified, with authenticated completion still pending. SC Node is not the current ARKTOR runtime: it is the public proof that preceded the newer, smaller ARKTOR Core foundation.

  • Your data is yours
  • No SC LABS tracking
  • Windows + Linux verified
  • Near-direct performance
  • Fail-closed controls
SC-AGENT / EXECUTION PIPELINELOCAL ROUTE READY
01
Resolve the routeExplicit override → matching rule → fallback → enabled local provider
DETERMINISTIC
02
Run the model loopPrompt → model response → tool call → tool result → next round
BOUNDED
03
Gate every toolAllow, ask or deny before file or shell I/O begins
FAIL CLOSED
04
Retain evidenceAudit events, policy hashes and verifiable proof bundles
AUDITABLE
01 · PUBLIC PROOFSC NodeOpen-source Rust alpha that proved the controlled-runtime direction in public.
02 · NEWER FOUNDATIONARKTOR CoreA smaller execution foundation shaped by those lessons, with a different product boundary.
03 · PRODUCT FAMILYARKTORThe current operational-AI family: product experiences, device paths and verified workflows.
See ARKTOR →

VERIFIED 5 AUGUST 2026

Alpha.2 is verified across Windows, Linux, public API gates and reproducible benchmarks.

The current main branch is protected by required Windows and Linux CI checks, an external public-API consumer, Rustdoc and package dry-run gates, and published raw benchmark evidence.
2 OSWindows and Linux run separate required CI gates for format, locked check, Clippy, workspace tests, release build and CLI smokerequired merge checks
65/65published benchmark processes completed successfully with no process failures and no stderr-producing measurementsraw evidence included
1.0742 msobserved warm-median difference between direct Ollama and SC Node on the published qwen:latest Windows reference run0.2014% · configuration-specific
APIan external consumer crate verifies the intentional alpha Rust API on Windows and Linux; Rustdoc and package dry-runs are gatedcrates not yet published
Near-direct model performance.
With a controlled runtime around it.

AI applications often need the same critical foundations: provider routing, tool execution, permissions, workspace boundaries and reliable evidence. Rebuilding those layers independently creates inconsistency and increases maintenance risk.

SC NODE proved those foundations in one modular Rust runtime: resolve the provider, run a bounded agent loop, approve or reject every tool action and retain evidence. That public proof now remains stable as a reference while ARKTOR Core takes the newer product-foundation direction with an even smaller execution boundary.

Rust was chosen deliberately for a compact native deployment model, predictable long-running behaviour and strong memory-safety guarantees. The published Windows reference run shows that the runtime can add routing, tools, permissions and audit controls while keeping observed warm-model latency close to a direct Ollama call.

On the measured Windows/qwen:latest configuration, direct Ollama recorded a 533.4315 ms median and SC Node 534.5057 ms: an observed difference of 1.0742 ms or 0.2014%. This is a dated, configuration-specific result — not a claim that SC Node accelerates models or outperforms Python frameworks.

WHY IT IS DIFFERENT

Your data is yours. The runtime is built that way.

When you run locally, SC LABS does not collect your prompts, files or tool activity. No SC LABS tracking, no analytics and no telemetry by default. If you deliberately choose a cloud model, only that request follows the provider you selected.
Local means localLocal model work stays on your machine instead of becoming SC LABS datawe do not need it
ControlPermissions, workspace boundaries and audit evidence are part of executionnot an afterthought
PerformanceNear-direct model performance with routing, tools, permissions and audit controlspublished evidence

WHAT THE PUBLIC ALPHA PROVED

One small runtime. The essential layers of an agent system.

SC Node was built as reusable execution machinery rather than an end-user product. Today it remains the public reference implementation that shows which controlled-runtime ideas were proven before ARKTOR Core took the newer product-foundation path.
01 / AGENT LOOP

Tool-result feedback

The model can request tools, receive structured results and continue reasoning through multiple bounded rounds instead of stopping after one completion.

02 / ROUTING

Deterministic model selection

A five-step router resolves the exact provider and model. Local providers are preferred and cloud execution cannot appear as an invisible fallback.

03 / PROVIDERS

Verified provider paths

Ollama is local and live-tested. NVIDIA NIM is cloud opt-in and live-tested. OpenRouter catalog and schema handling are verified; authenticated streaming completion remains pending.

04 / PERMISSIONS

Gate before I/O

Every tool decision resolves to allow, ask or deny before file or shell execution begins. Unknown tools and non-interactive approval requests fail closed.

05 / SANDBOX

Workspace boundaries

Paths are canonicalised and checked against allow and deny roots, including Windows-specific edge cases such as UNC paths, device names and alternate data streams.

06 / EVIDENCE

Audit, contracts and proof

Tool outcomes can be recorded in append-only JSONL, constrained through strict execution contracts and packaged into hash-linked proof bundles with secret redaction.

07 / TOOLS

File and shell execution

Read, write, directory listing and argument-vector shell tools share the same central permission path, timeout handling and audit model.

08 / MEMORY

Memory foundation

The workspace includes a tested backend-neutral memory and RAG crate with persistence, filters and workspace isolation. Runtime integration remains an explicit alpha task.

09 / DELIVERY

Cross-platform alpha baseline

The public project builds as the sc-agent command-line binary plus reusable crates, with Windows and Linux verification and an external consumer gate for intentional public Rust APIs.

SC NODE ALPHA ARCHITECTURE

The public proof stayed small because responsibilities stayed separate.

This diagram describes SC Node itself. It is historical architecture evidence, not a diagram of the current ARKTOR Core implementation.
Consumer layerDedicated agentsWindows applicationsCLI integrationsPrototype products
↓ task, model preference and workspace context
SC Node coreAgent loopProvider routerMessage contractsConfiguration
↓ selected model path and requested actions
Providers & toolsOllamaNVIDIA NIMOpenRouterFile & shell tools
↓ every controlled action
Control layersPermissionsWorkspace sandboxAuditContracts & proof

ARCHITECTURAL DIFFERENCE

A reusable native core instead of duplicated infrastructure.

The comparison below focuses on architecture, deployment and governance. It avoids universal performance claims and highlights the concrete design choices implemented in SC NODE.
AreaLarge interpreted agent stackSC Node approach
RuntimeInterpreter, environment and package graph remain part of deploymentOptimised native Rust binary and reusable crates
ScopeFramework may define UI, orchestration, memory and tools togetherExecution core only; products choose their own interface and higher layers
RoutingProvider behaviour can depend on framework plugins or implicit defaultsDeterministic route resolution with a hard cloud gate
Tool safetyOften added through application-specific middlewareCentral permission decision before every supported tool action
EvidenceLogging varies by application and integrationAudit events, policy hashes and proof verification are distinct modules
ExtensionAdopt the surrounding framework conventionsAdd or replace crates while retaining the same execution contract

RUN IT YOURSELF

Public source. Reproducible checks.

SC Node requires Rust 1.85 or newer and provides locked build, CI, public-API and benchmark verification paths.
WINDOWS POWERSHELL / QUICK START
git clone https://github.com/SC-LABS-ai/sc-node
cd sc-node
cargo build --release --locked

.\target\release\sc-agent.exe init
.\target\release\sc-agent.exe doctor
.\target\release\sc-agent.exe run "List the Rust files in this workspace"

HONEST PUBLIC ALPHA

A strong cross-platform alpha baseline, with clearly documented next steps.

SC Node already verifies its core runtime, controls, public API baseline and performance evidence. It does not claim production readiness or absolute security.

Verified now

  • Version 0.1.0-alpha.2 release baseline
  • Required Windows and Linux CI merge checks
  • Bounded tool-using agent loop
  • Deterministic local-first provider routing
  • Ollama and NVIDIA NIM live-tested
  • OpenRouter catalog and schema verified
  • Fail-closed permissions and workspace boundaries
  • Audit, execution contracts and proof bundles
  • External public-API consumer and package dry-run gates
  • Published reproducible benchmark evidence

Still being completed

  • macOS verification
  • Authenticated OpenRouter streaming completion test
  • Memory/RAG integration into the main runtime
  • True incremental Ollama streaming
  • Stronger process containment and resource limits
  • Cryptographically tamper-evident audit storage
  • TOCTOU and shell-boundary hardening
  • Publication of selected crates to crates.io
  • Final stable Rust API

TECHNICAL FAQ

What SC Node is — and what it deliberately is not.

Is SC Node an end-user desktop application?

No. SC Node is a command-line binary and modular Rust workspace published as an experimental reference. The current SC LABS product direction is ARKTOR; SC Node remains available as the earlier open-source runtime proof rather than the runtime beneath today's product family.

Why keep SC Node public?

Because it is useful evidence. It shows the earlier controlled-runtime architecture, cross-platform gates and measured performance in public source. Keeping that proof stable also makes the evolution toward the smaller ARKTOR Core visible instead of quietly rewriting history.

Is ARKTOR built on SC Node?

No. SC Node is the earlier public proof of concept. ARKTOR Core is the newer, smaller product foundation shaped by lessons from that work. The two should not be read as the same runtime under different names.

Does it send data to the cloud automatically?

No. Ollama is the default local provider. Cloud providers must be enabled explicitly, credentials are read from environment variables and there is no silent cloud fallback.

What does the published benchmark support?

It supports the narrow statement that SC Node preserved near-direct model performance on the measured Windows/qwen:latest configuration while adding routing, tools, permissions and audit controls. It does not show that SC Node makes models faster or that it is universally faster than Python frameworks.

Can developers use the Rust crates?

An intentional alpha API baseline is defined and verified through a separate external consumer crate on Windows and Linux. The crates are not yet published to crates.io, and explicitly experimental surfaces may still change between alpha releases.

SC Node logo

CONNECT. ROUTE. EXECUTE.

SC NODE is the public proof that informed the smaller ARKTOR Core foundation.