required merge checksSC LABS / OPEN-SOURCE PROOF OF CONCEPT / ALPHA.2
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
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.raw evidence included0.2014% · configuration-specificcrates not yet publishedNear-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.we do not need itnot an afterthoughtpublished evidenceWHAT 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.Tool-result feedback
The model can request tools, receive structured results and continue reasoning through multiple bounded rounds instead of stopping after one completion.
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.
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.
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.
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.
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.
File and shell execution
Read, write, directory listing and argument-vector shell tools share the same central permission path, timeout handling and audit model.
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.
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.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.| Area | Large interpreted agent stack | SC Node approach |
|---|---|---|
| Runtime | Interpreter, environment and package graph remain part of deployment | Optimised native Rust binary and reusable crates |
| Scope | Framework may define UI, orchestration, memory and tools together | Execution core only; products choose their own interface and higher layers |
| Routing | Provider behaviour can depend on framework plugins or implicit defaults | Deterministic route resolution with a hard cloud gate |
| Tool safety | Often added through application-specific middleware | Central permission decision before every supported tool action |
| Evidence | Logging varies by application and integration | Audit events, policy hashes and proof verification are distinct modules |
| Extension | Adopt the surrounding framework conventions | Add 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.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.
CONNECT. ROUTE. EXECUTE.