One declarative surface · bounded translation · a path to proof
SenseUI + Sphere
SenseUI describes the interface; Sphere is being developed to carry declared intent across supported representations. Together they point toward a system where the surface and the program beneath it can be expressed, checked, and understood as one.
This page is built from Rust-authored SenseUI declarations: a typed projection model and element tree produce HTML, while Rust-authored style rules produce responsive CSS. A small browser adapter handles interaction. Sphere's Rosetta and 0xAlexandria components explore bounded mirroring among declared JSON, Rust, and raw-machine forms; this remains a limited research profile, not arbitrary compilation.
The next step is to connect Sense-Rust and SenseUI declarations to Vero-authored contracts and independently checked proofs for explicit, supported profiles. That integration is a direction, not a capability this page or Sphere currently proves. A reproducible clean-room build is also a goal: the browser output uses local HTML, CSS, assets, and a small adapter, while the Rust build still uses its declared crates.
One persistent surface
The smart bar, theme controls, assistant entry, and ambient field stay mounted. Navigation changes the selected view in place rather than loading a separate page.
Rust generates the browser layer
SenseUI declarations generate standard HTML and CSS, with a small JavaScript adapter for browser events. The result can run in ordinary browsers today.
A step toward native SenseUI
This page demonstrates the shared-surface direction in a browser. A native SenseOS renderer and a complete cross-device runtime remain under development.
Universal Constraint Computing explores how a system's purpose and limits can be made explicit. Sense-Rust grows from SenseUI's declarative work toward a clearer, efficient way to express system structures and operations with Rust types. SenseOS is the operating-system foundation; SenseUI is the shared surface. Sphere brings Rosetta and 0xAlexandria together for syntax-independent, intent-driven mirroring among bounded JSON, Rust, and raw-machine forms, with calibrated support for more languages as a research goal.
These efforts are at different stages and are not yet one integrated product. The opportunity is to connect them through tested, reviewable milestones rather than assume the finished system.
Supporting projects and research
Focused projects build practical capabilities around that direction.
Synapse · agent coordination
Project documentation describes a Rust agent host with a terminal interface, state, model routing, and approval-gated tools. Device acceptance and production release gates remain open.
Android ARM64 acceptance, provider/MCP integration review, and release validation.Useful next step:
MemoryCore · curated project memory
A local Rust storage and retrieval component. Retrieval is not a pretrained semantic model.
Portability, retrieval-quality evaluation, and storage reliability review.Useful next step:
Nautilus · early model and learning experiments
Recovered notebook and initialized runtime artifacts; no trained model, complete source dataset, or completed experiment is verified.
Reproduce a baseline and establish licensed data before reporting measured results.Useful next step:
Funding and practical support
Aligned support can advance Sense-Rust and SenseUI integration, validate Sphere's bounded translation work, and advance selected engineering milestones through measured, independent trials. Independent review, accessibility work, and target-device testing are also priorities.
Cash startup funding is the priority; grants, compute credits, and technical or commercial partners can also help. The near-term goal is evidence-backed progress on selected milestones, not a claim that every project is production-ready.
Funding amount, legal entity details, and investment terms are not yet published.
A gated beta environment for controlled testing of chat, project tools, and restricted development environments.
Restricted beta workspace unavailable: its protected URL is not configured.
Beta chat environment
The Open WebUI beta workspace is configured in a deployment template with one read-only R17 gate-status tool. The workspace and model calls are not live until Cloudflare Access, the Tunnel, and account credentials are configured. The server-side template lists GLM-4.7-Flash and Gemma 4 26B A4B as Workers Free options, subject to the shared 10,000-Neuron daily account allocation and current model availability. This is limited free usage, not unlimited inference.
Project workspace
Open Terminal runs arbitrary shell commands inside a project-scoped workspace. Sense-Rust contains A17/A18 decision and signature components plus a root-signed reviewer-registry route. Its root anchor and time/epoch policy still need an external protected authority, and it does not bind or intercept exact terminal commands. No such action mediator is integrated here, so terminal access stays disabled until that boundary is implemented and reviewed.
Public account creation is off. Access is limited to the designated beta-testing environment and its configured access rules.
Research framework
UCC · Universal Constraint Computing
Proudly produced by DarkBlaze Group
Make a system's purpose, permissions, and limits explicit before it acts.
The lens
UCC is the lens for our work: describe what a system is asked to do, what it may do, and what must remain outside its reach. The research considers context, authority, possible effects, uncertainty, and resource limits alongside the requested outcome.
Current status
This is ongoing framework research. Complete end-to-end enforcement is not yet established.
UCC at a glance
A conceptual frame for declaring intent and boundaries; it is not a claim that complete enforcement is already available.
A computer environment designed around one coherent surface and clearly bounded system behavior.
The role
SenseOS is intended to provide the system foundation: starting the computer, managing programs, files, and devices, and presenting a consistent workspace.
Work so far
Prototype work has tested parts of boot handoff, persistent storage, program admission, filesystem access, capability checks, and interface input. These are partial paths, not a complete or production-ready general-purpose operating system.
One shared object space
The current Sense-Rust design gives objects stable identities and typed interfaces; filesystem paths bind names to those objects, making the filesystem one projection of shared system state. The object model includes data, devices, processes, services, buses, and network endpoints or connections. A journal records state transitions, while authorization remains a separate check. This is an implemented architectural foundation in the reviewed source, not a claim that every object provider is complete.
Where the network fits
This model gives a remote resource a natural place in a shared namespace: a future adapter could expose authenticated remote objects through explicit bindings and scoped rights. The reviewed source does not yet implement a complete network filesystem transport, peer authentication, or remote operation flow. That is the next architectural seam to prove, not a current capability.
Compatibility, in stages
The long-term goal is to run applications from many operating-system families through SenseOS services and the SenseUI surface. Existing syscall catalogs are research inventories, not application compatibility. In the reviewed Linux x86_64 route, only write, exit, and exit_group are handled; unsupported calls return ENOSYS. No AI syscall translator or general foreign-app runtime is implemented. Progress needs explicit profiles for each ABI, architecture, binary format, runtime, and app framework, with deterministic adapters and real application tests. AI may help draft those adapters; typed contracts, authority checks, and validation must govern execution.
How it relates
SenseOS is intended to host the shared SenseUI surface as native system userspace. Other operating systems would open the same surface as a web app, so content can move across environments without changing the interface. This remains a product direction; this website is not a running SenseOS system.
A shared visual workspace that aims to make different tools and content feel like one environment.
The direction
SenseUI is being developed around Sense-Rust as a declarative language for a common surface. The goal is for one interface to stay familiar while its projected content adapts across web, mobile, and SenseOS, so users do not feel they have switched mediums.
Project lineage
SenseUI carries forward the Rust UI work explored under the earlier AchetUI and Uni-UI names. SenseUI is the current name for the shared-surface product direction; the older names describe project history, not separate finished products.
From declarations to Sense-Rust
Sense-Rust grew from the declarative work behind SenseUI. The design aim is a standalone, Rust-derived language: its own defined syntax, intent model, and toolchain, designed to carry explicit human-approved intent, permissions, and machine-checkable contracts from firmware and kernels through interfaces and web apps. A proposed next milestone is a small language slice with mandatory contracts for its verified profile, then a Sphere mirroring path that emits a proof-carrying executable artifact checked against that language's semantics. The goal is a compile-free user workflow, not a claim that translation disappears: producing executable output still requires a semantics-preserving implementation. A successful mirror or round trip alone does not prove correctness; the contract must match approved intent, translation must be proved to preserve it, and an independent checker must validate the evidence. AI could draft implementations and proofs, but it cannot approve intent or certify its own claims. Verus is a candidate verifier for a carefully bounded Rust subset, not the language identity. This is a direction, not a current compiler, Sphere integration, or end-to-end proof; hardware and unverified-code boundaries would need explicit treatment.
The language ambition
The design target is to express structure, styling, interaction, and 3D scenes together, including a planned Three.js-compatible browser path, with standard web markup generated for non-SenseOS environments. R17 tests source generation only; it does not provide a general 3D renderer or a universal native runtime.
Try the surface
Use the top bar to move between Home, Work, and About. The bar, assistant entry, theme controls, and ambient background stay in place as the displayed view changes. This is the first DarkBlaze website generated from its SenseUI Rust APIs.
What the browser runs
SenseUI Rust declarations generate standard HTML, CSS, and a small JavaScript adapter that ordinary browsers run. This is a real browser-facing SenseUI expression, while the native SenseOS surface and complete cross-device runtime remain development goals.
Current stage
Rust-based interface libraries and runtime foundations are in development. This page demonstrates generated browser output; it is not a live desktop compositor and does not establish a protected native system boundary.
AI in this build
The Site Secretary is designed for general conversation as well as questions about DarkBlaze. When a question relates to the group, it can search the complete site and its project catalogue, then suggest bounded actions on this surface: open a known view, filter a project record, or search page content. It can use recent turns from the current page session to understand follow-up questions, but it does not save a lasting user profile. DarkBlaze claims must stay grounded in the site; when a detail is missing, the Secretary should say so plainly. Its voice should be warm, calm, direct, and exact. Browser code accepts only allowlisted actions; it cannot edit source code or run arbitrary commands. A live model can be configured only through a protected server endpoint, with no provider key in the page. This preview uses local prepared replies until that endpoint is supplied.
Illustrative surface study · Photo by Dzo on Unsplash
How this page reaches a browser
A simplified view of the current R17 build path; this does not imply a native SenseOS runtime.
I began BlackBlaze in 2011 as a graphic design group, creating websites and corporate identities. After working in real estate, I moved into systems research and engineering, then restarted the group as DarkBlaze in 2025. That path led me to formal-verification experiments, including working models of seL4 and Muen and a laptop-based Qwen 2.5 inference-appliance experiment.
DarkBlaze is now an independent, early-stage technology initiative exploring how computing can express intent, respect declared limits, and remain coherent across devices. The projects take different routes into that question, from a shared interface to systems research and engineering.
At DarkBlaze, we ask how computing can be made as precise and verifiable as the laws that shape the natural sciences.
T. Billy Ekkerd · Perspective
How the ideas connect
A high-level map of the portfolio: state the intent, express a usable surface, and build the system foundations that could support it.
DeclareIntent, permissions, limits→
ExpressOne coherent interface→
BuildSystem and runtime foundations
History · current work · next steps
A path shaped by evidence and support
Explore our history, recorded project work, and possible next steps. Future work depends on evidence and support, with no delivery dates promised.
Drag to rotate; use the zoom controls or scroll over the sphere to reveal nearby project labels. Choose a point or search the work to explore its recorded history, current evidence, and possible next steps.
Zoom 1.0× · labels on selection
Connected projects · evidence to possible next steps
The Sense line and its neighboring research
Each track links recorded work to a possible direction. The paths compare stages, not calendar dates: no delivery schedule or assured outcome is implied.
Recorded foundationCurrent evidenceConditional next
SenseUI
Sense-Rust
SenseOS · SenseFS
Sphere · Vero · Rosetta · Alexandria
Universal Constraint Computing
Synapse · DarkBlaze Core
Nautilus
What the next stage needs
Aligned investmentTime and runway for focused milestones
Compute and toolsResources to build and evaluate prototypes
Engineering partnersPeople to mature selected project paths
Independent validationReview claims, limits, and results
Engineering record · 2026
Senticore: a local AI appliance experiment
I assembled Linux boot components, startup integration, llama.cpp, and a GGUF model into a laptop-based local AI appliance. The Linux pieces were part of the encapsulation that allowed the machine to boot into the model runtime. In the recorded path, Linux and its startup code hand off to llama.cpp, which loads the model and runs inference on the laptop's physical hardware.
The screen label kernel.gguf names the model file; it is not the Linux kernel. The captures show boot and runtime setup failures followed by llama.cpp loading a GGUF model and returning text. The model's self-description and prompt responses are not independent verification of the loaded weights or of physical awareness. This account describes the Linux-based appliance experiment shown here and does not claim that the GGUF model itself ran as firmware or that the work was the first of its kind.
User-supplied screen capture · capture time unverifiedLinux boot and init failureThe visible Linux boot log ends with failed init candidates and a kernel panic. It documents a failed boot attempt, not a successful handoff.User-supplied screen capture · capture time unverifiedStartup command debuggingThe startup output reports an awk syntax problem and that /bin/llama-cli could not be found.User-supplied screen capture · capture time unverifiedRuntime library debuggingThe startup output reports that libssl.so.3 could not be loaded, documenting a runtime dependency failure.User-supplied screen capture · capture time unverifiedLocal model inferenceThe screen shows llama.cpp loading a GGUF artifact named kernel.gguf and returning a response. The filename is the model artifact's label, not evidence that it is a Linux kernel.User-supplied screen capture · capture time unverifiedSenticore prompt sessionA prompt addresses the running model as Senticore and receives a response. The model's text is output from the prompt, not independent evidence of awareness or hardware access.User-supplied screen capture · capture time unverifiedFollow-up model interactionA further llama.cpp interaction includes the model identifying itself as Qwen. A model's self-description is not independent verification of loaded weights.
Capture provenance: the six Senticore PNGs are user-supplied full-screen captures copied byte-for-byte. Capture time has not been verified. Five PNGs contain a caBX/C2PA metadata chunk that has not been parsed or cryptographically validated; one has no such chunk. Workspace file dates record placement here, not screen-capture time. Open any image at full resolution to enlarge its recorded text; the screen pixels are unchanged. Earlier camera photographs and perspective-normalized crops remain in local project history but are not used in this gallery. The separate DarkFS loader photograph retains its original filename and EXIF provenance.
DarkFS loader record
A separate restored photo shows DarkFS reporting “Loading… OK, booting…”, alongside a “no such partition” message. It records a loader attempt and handoff message, not a confirmed successful operating-system boot.
DarkFS loaderLoader messages are visible; successful OS startup is not established.
Repository archive · interactive project index
Explore the full project record
This index covers all 129 repositories currently owned by the connected GitHub account. It includes products, components, research, source archives, and support repositories; these are not separate finished products. Search a name or topic, then open any point for its nutshell, history dates, and recorded status.
The recovered Arc set contains Arc001–Arc020, Arc022–Arc025, and Arc26. Arc021 is absent from both the recovered archive index and the current GitHub inventory; the final project is named Arc26 in the source tree.
129 repository records
A shared surface
SenseUI explores one interface that can present different content across the web, mobile devices, and a future SenseOS environment. This R17 website is its first browser expression, generated from Rust and rendered by ordinary browsers.
Systems with declared boundaries
Universal Constraint Computing explores how a system's purpose, permissions, context, and limits can be made explicit. Sphere explores bounded mirroring between JSON, Rust, and raw-machine representations. Both remain active research directions.
Research at different stages
SenseOS, Sense-Rust, and the other portfolio projects are at different stages of exploration and implementation; the website describes their direction without presenting them as finished products.
How we work
We make individual contributions visible, use each person's skills, and distinguish demonstrated prototypes from goals and open questions. Progress should be tested and described at the level the evidence supports.
What moves the work forward
We are seeking aligned investment and engineering, research, and compute partners to help fund focused prototyping, validation, and the next development milestones. We want to grow the work without giving up independent technical direction or overstating what is already built.
Intent-driven mirroring: compile and decompile between bounded representations while keeping the declared goal and evidence in view.
What mirroring means
Sphere's current scope is JSON, Rust, and raw-machine representations. Within supported profiles, it explores compiling from declared intent into a target form and mirroring a supported form back for comparison, reducing dependence on writing every target syntax by hand. Each route is intent-driven, bounded, evidence-checked, and must refuse work it cannot support.
The larger implication
The design idea is not tied to one programming-language syntax. If a language can be calibrated against explicit intent and its output verified within declared bounds, the same compile-and-mirror loop could extend to it. We call this direction syntax-independent or language-independent mirroring. Broader language coverage is a research goal, not a current capability; it does not promise arbitrary code generation, zero translation effort, or lossless reversal.
Why it matters
If this direction matures, software builders and AI-assisted tools could make low-level choices easier to inspect, compare, and constrain. That could have wide consequences for portability and accountable automation. It is a research opportunity, not a current guarantee of safe or correct output.
One programme
Sphere is the umbrella effort. Vero is being adapted as its verification and evidence gate, including declared constraints and signatory checks. Rosetta explores structured translation between intent and target-specific representations; 0xAlexandria organizes machine-readable instruction profiles with their sources, scope, and evidence. They are parts of one effort, not separate products on this site.
Where it stands
There are working components and bounded, independently checked examples, but they cover selected forms and targets. Sphere is not a general-purpose compiler, a complete catalogue of every processor, or an end-to-end proof that generated programs behave as intended.
What support can unlock
Focused engineering, stronger target coverage, independent comparison against trusted tools, and end-to-end validation could show where the approach is useful and where it must refuse unsupported work.
Website information · DarkBlaze Group review required
Privacy notice
Proudly produced by DarkBlaze Group
This notice describes the current R17 browser preview. Hosting-provider logging and retention have not been verified.
Information handled by this page
This static site does not run analytics, set tracking cookies, save browser storage, or create application-level visitor or interaction logs. The local clock uses your device time; theme choices stay in memory for this visit. When you use the live Site Secretary, your message (up to 240 characters), up to eight prior turns (1,200 characters per turn), and up to 4,600 characters of focused excerpts from the current and relevant site sections are sent through a Cloudflare Worker to OpenRouter and the selected model provider to generate a reply. The deployed model is Cohere North Mini Code (free) through OpenRouter. The site does not retain the conversation; Cloudflare, OpenRouter, and the model provider may process request data under their own policies. Conversation context stays in page memory and is cleared when you clear it or leave/reload the page. This R17 preview does not yet include a weather service and does not request location. When local weather is added, the browser must ask for location only after you choose that feature, and the notice must name the weather provider and explain that it receives the coordinates.
Restricted beta workspace
The separate restricted beta workspace is a local deployment template and is not confirmed live. If deployed as configured, Open WebUI stores application data in its persistent Docker volume, and chat prompts go from that server to the configured Cloudflare Workers AI model. Cloudflare Access provides the upstream sign-in gate; Open WebUI uses a configured account. Sense-Rust contains A17/A18 decision and signature components and a root-signed reviewer-registry route, but the root anchor and caller time/epoch policy still require a protected authority. No R17 service binds those results to exact Open Terminal commands or mediates execution. The terminal remains disabled until that action boundary is implemented and reviewed. Hosting, account, and provider retention terms need DarkBlaze Group review before use.
Contact handoffs
The Site Secretary keeps recent conversation in page memory for this visit, and you can clear it at any time. If you choose an email handoff, your email app opens a draft with the details you selected; nothing is sent until you review and send it. Choosing WhatsApp passes the prepared reply to WhatsApp. The site does not receive or retain either handoff.
Connection data and hosting
The website code does not implement application-level IP logging or send IP addresses to analytics. The web host, CDN, DNS, or network providers may still process connection data. Their logging and retention practices have not been verified; this notice cannot promise that no provider records an IP address.
Changes and contact
This notice reflects the current R17 source and needs DarkBlaze Group review before public release. Questions can be sent to admin@darkblaze.org using your own email app.
These plain-language draft terms describe the intended use of the DarkBlaze Group website. They are not legal advice and have not been reviewed by counsel.
Using this website
This website introduces DarkBlaze Group research and development projects. Descriptions are informational, may change, and are not a delivery commitment, product guarantee, investment offer, or professional advice.
Project status and materials
Prototypes, demonstrations, and research summaries are at different stages of maturity. Do not rely on a prototype or visualization as a production service. Brand assets and project materials remain subject to their respective ownership and license terms.
Contact and availability
Email links are optional handoffs to your own app. You choose whether to send a message; the static site does not send messages or promise a response time. The website may be updated, interrupted, or withdrawn. These draft terms need DarkBlaze Group and jurisdiction-specific legal review before launch.
DarkBlaze aims to support keyboard use, readable contrast, reduced-motion preferences, responsive layouts, and clear control names.
Current implementation
R17 includes keyboard-operable links and controls, visible focus styling, responsive layouts, and reduced-motion behavior for the hero film. Browser-level accessibility scans and manual assistive-technology checks have not been run on this R17 checkpoint.
Current limits
A source-level review cannot establish full accessibility. Screen-reader, switch-control, zoom, and physical-device testing remain outstanding. Animated visual material may need additional descriptions.
Report a barrier
Email admin@darkblaze.org with the page and task affected, plus a way to reply if you want one. Your email app opens a draft; you choose whether to send it. Avoid sensitive information unless it is needed.
This page records source material and external components used by the current R17 browser surface.
Website template
The retained R15.2 source package includes the Mercer Lite template by Mike Smith Design, licensed for personal and commercial use and modification. Attribution is not required, though credit is appreciated. The licence prohibits reselling the template itself or presenting it as original work. See https://github.com/mikesmithdesign/mercer-lite.
Images and browser dependencies
The portrait and DarkBlaze logomark are served as local assets from the retained R15.2 package. Three additional PNG concept images are bundled locally and credited beside their sections: a circuit-board photo, a glass-render study, and a radiating abstract. They are illustrative, not product screenshots or implementation diagrams. Each source was marked free to use under the Unsplash License; attribution is included. R17 loads its own HTML, CSS, JavaScript, local images, and hero video without an external browser-side library.
Build dependencies
Rust crates are used at build time to generate the browser files. Their notices and licence terms remain part of the SenseUI repository's dependency and release review.
