R16 is described with SenseUI's Rust APIs. A typed projection model and Rust-built element tree produce one browser document; Rust-authored style rules generate its responsive and accessibility-aware CSS. A small browser adapter changes the visible projection while the surrounding surface stays in place.
One persistent surface
The smart bar, theme controls, assistant entry, and HNDEN 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. Rust-Sense 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. HNDEN is a separate first-generation neural-network design exploration.
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 Rust-Sense and SenseUI integration, validate Sphere's bounded translation work, and give HNDEN the engineering time and compute needed for measured prototype 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.
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 Rust-Sense 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 Rust-Sense 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 Rust-Sense
Rust-Sense grew from the declarative work behind SenseUI. The founder's vision is for it to become 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. R16 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 R16 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 neural-network design, 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 BIOS-to-Qwen 2.5 handoff on a laptop.
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 machine-learning design.
At DarkBlaze, we ask how computing can be made as precise and verifiable as the laws that shape the natural sciences.
Founder perspective · paraphrased
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
The first three milestones describe work already done. The forward path is a direction, not a dated commitment or a quantified funding or performance forecast.
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
Rust-Sense
SenseOS · SenseFS
Sphere · Rosetta · Alexandria
Universal Constraint Computing
HNDEN
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
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 R16 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
HNDEN is a first-generation neural-network design prototype. SenseOS, Rust-Sense, 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.
HNDEN is our first-generation neural network design prototype: a spark of vision for systems whose relationships and changing activity can be understood as one connected whole.
This page presents the first generation of our neural network design idea. The moving field makes its central intent visible: explore how connected elements and their relationships could be considered together. It is an early design prototype, not a claim of a complete or validated neural network.
How it works as an idea
At a concept level, the design treats the network as a connected field. Changes among parts should be expressible in the wider pattern, so the system can preserve context as activity shifts. The motion is illustrative and does not document the implementation.
What we plan to build
Our plan is to turn the design into a measurable working prototype, validate its behavior, and test efficient execution across edge devices and larger compute. That requires dedicated engineering time and meaningful compute access.
Build it without losing the point
We are seeking aligned investors and research partners who can help fund engineering and compute while protecting privacy, user agency, and independent technical direction.
This is an early design prototype and visual explanation. It does not claim a complete, production-ready, or independently validated neural network.
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. 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.
This notice describes the current R16 browser surface. 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. If live AI is disabled in the build, questions are answered with local prepared replies and are not sent to an AI provider. If live AI is enabled, each submitted question may include recent turns from the current page session and relevant site excerpts; that request is sent through the configured AI service to its model provider. Provider processing and retention terms must be reviewed before launch. Conversation context is held only in page memory and is cleared when you clear it or leave/reload the page. This R16 build 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.
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 R16 source and needs owner 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 owner 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
R16 includes keyboard-operable links and controls, visible focus styling, responsive layouts, and a reduced-motion stylesheet. Browser-level accessibility scans and manual assistive-technology checks have not been run on this R16 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 R16 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 founder portrait and DarkBlaze logomark are served as local assets from the retained R15.2 package. Four additional PNG concept images are bundled locally and credited beside their sections: Mirella Callage's neural illustration, Umberto's circuit-board photo, Dzo's glass-render study, and Marek Pavlík's 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. R16 loads its own HTML, CSS, JavaScript, and local images 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.
