#
Deterministic Engineering is a Library for organizing engineering work around explicit Questions, models, obligations, methods and evidence. A downstream repository selects reusable definitions, binds its own project inputs and keeps its architecture, documents and decisions associated with the checks behind them.
Scheme/POO owns the engineering declarations and composition. ASCENT answers declared relational questions. Rust, QNT, Lean and SysML provide selected method capabilities. The TypeScript render package presents the selected model and source context through static D2, HTML, SVG and PNG artifacts.
This is the engineering organization used by this repository: the Library publishes reusable definitions, a Profile selects them, and a Scenario binds actual project inputs. The project boundary owns its architecture model, Org artifacts and decisions. The complete overview includes the numbered purpose, core architecture, independent boundaries and project artifacts, followed by current source observations and open gaps. Arrows point to dependencies.
Ownership component detail · Questions and editable D2 · Project SysML
Selected Rust, QNT, Lean and SysML methods consume the project’s bound inputs
and retain their result semantics and source associations. ASCENT derives answers
from declared facts and rules; Aitia owns independent policy-bound review.
The TS Library presents these models and associations. Rendering does not grant
evidence or review authority. This Case currently remains capture-blocked.
| Part | Owns | Project use |
|---|---|---|
| Library | Reusable models, obligations, method bindings, policies and contracts | Publishes definitions and their identities |
| Profile | Model/parent selection, two policies, methods, catalog and mapping choices | Selects published definitions without copying their ownership |
| Scenario | Repository inputs, origins, associations and capture preparation | Binds the selected definitions to one project use |
| Project | Confirmed intent, responsibility and use scope | Composes the selected Profile and Scenario |
The source contracts and declarations are authoritative. Version identity is read from its owning declaration or package metadata, not from a namespace, diagram or duplicated version table.
<<architecture>> The arrows below describe responsibilities and dependencies, not execution order. The README uses one sketchbook visual language. Other styles remain available through the render package and its declared D2 variants. Aitia’s end-to-end review integration remains a target boundary for this Case.
Detailed repository dependency diagram
Editable D2 · Project SysML model · Engineering ownership
| Source | Responsibility |
|---|---|
| library/ | Domain definitions and Scheme drivers, including project organization and concurrency/resource control |
| profiles/ | Independent project and workload choices |
| scenarios/ | Application bindings, input acquisition and source adapters |
| projects/ | Actual project entrypoints and project test policy |
| languages-engineering/ | Target-language projects and source, including Rust/Cargo inputs |
| packages/render/ | Functional static-rendering package and optional OpenSysML SDK projection |
| packages/render/examples/ | Package-owned render cases and domain-specific compositions |
| docs/ | Org design arguments, D2 projections, decisions and candidate image snapshots |
The root init.ss uses Yuanxu’s declared module loading. The build.ss consumes declared public roots. This repository reuses POO/Core/Flow/module and contract mechanisms; it does not define another package loader or model runtime.
The LLM agent chooses investigations and proposes Library extensions; ASCENT
exposes evidence and changed premises; Aitia retains admission and authorization.
These relationships form a feedback loop, not a fixed sequence of agent actions. The actual
capture preparation source still returns
capture-blocked and capture = #f for DE-CASE-01. A diagram or successful render
does not issue a capture, accepted query view, review result or authorization.
Editable D2 · SVG export · Architecture/document/decision contracts
Methods and content checks must keep their actual inputs, result semantics, source/revision associations and open findings. ASCENT reasoning consumes explicit facts and rules; support does not grant execution authority. Aitia review and actual publication/use retain their own policy and responsibility boundaries.
The SDKs own syntax and model semantics. Render adapters retain their identities and explicitly bind model/view/source snapshots before scene composition.
Source audit and positive/negative controls
@deterministic-engineering/render is a static, functional Library. Questions, copy, model/source links and resource selection stay in D2/SysML and the project declarations. Domain composition is a pure function. Export effects measure actual browser text/fonts/images and return artifacts plus rendering facts.
| Choice | Declaration / extension boundary |
|---|---|
| Diagram kind | Open project identifier; architecture and Workflow purposes stay separate |
| Organization | Project layout / presentation and a domain compositor |
| Visual style | Ordered immutable theme layers: typography, surfaces, strokes, palette and spacing |
| Icons | Ordered project-selected SVG packs, independently replaceable |
| Variant | D2-selected kind, layout, themes and icon packs over the same captured model |
The package reuses D2 model compilation, ELK.js scene layout/routing, parse5 HTML parsing, Rough.js options/primitives, XYFlow connector paths and Playwright export. It has no interactive whiteboard or React runtime. A node diagram or swimlane is one example, not the framework’s entire diagram vocabulary.
The project-owned variants select kinds, a theme and a glyph pack defined only
in the consumer. Their source associations and current blocked state stay intact.
Architecture: D2 · Complete hand-drawn architecture
Workflow: D2 · Separate hand-drawn Workflow
Use the declared Bun version from render CI and its pinned package/browser dependencies. Run from the repository root:
bun install --frozen-lockfile
bunx playwright install chromium
bun run typecheck
bun run test
bun run test:exportRun the package-owned cases from the same repository root:
bun run test:examples
bun run example:case
bun run example:compare
bun run example:overviewsCandidate outputs and source/browser receipts are written to .cache/render/.
Tests include unknown declarations, model/source mutation, invalid relations and
ports, hidden Questions, unsupported primitives and failed image loading.
The Linux/macOS workflow runs the same entries with the existing resource
bounds. Render CI checks
are authoritative for the actual tested commit.
The render architecture and view-authoring Workflow are distinct current diagrams. Their D2 sources are maintained alongside the SVGs and rendered through the measured TS scene API. The active SVGs and PNGs come from the same font-settled scene; the old raw-D2 rendering path has been removed.
The repository-root package.json is the Render version and dependency source.
Downstreams install the reviewed Git revision with Bun; Release attachments are
optional distribution. Each D2 compilation owns an ephemeral process and worker;
the Promise settles only after native process close, including IPC failure paths.
No compiler pool or fallback renderer is introduced. See the
compiler lifecycle and release audit for acceptance and downstream recovery.
The canonical dependency/prelude declaration is gerbil.pkg. The compiler is Gerbil; package commands own dependency resolution, checkout, manifests, compilation and loading. Current commands and existing budgets live in Justfile:
just deps
just build
just test
just test-project-formationThese Scheme/package gates are separate from TS rendering qualification. Historical dependency/cohort results retain their original scope; this render PR does not establish a fresh full Scheme cold-build or runtime admission result.
- Documentation index — the complete design/research history.
- Current render audit — fixed assumptions removed, owners, extension contracts and controls.
- Rendering research — references and decisions behind the visual approach.
- DE-CASE-01 — this Library as the engineering case.
- Gateway case — application questions, obligations and open work.
- Current and historical view index — architecture and Workflow artifacts with explicit scope.
The repository is under active design and refactoring. Candidate models, source observations, rendered explanations, method evidence and independent review results remain distinct. Open findings and counterevidence stay visible for audit.
Render-owned examples live under packages/render/examples/. Visual styles, palettes, typography, density, ELK preferences and icon packs compose independently. Model Questions/content remain in D2/SysML; optional pure heading parts distinguish Question role markers from domain Answer glyphs and measure the complete group. The default exported canvas is explicit, with an optional transparent mode. See 10.144 contracts and acceptance.
Detailed architecture: Sketchbook dependency view. Workflow: Sketchbook authoring Workflow.
Design declares the reader, message and model fidelity. Taste composes pure choices before rendering and inspection after export. Questions select subjects, source observations select gaps, and the existing ELK layout measures and routes the resulting view. Themes remain replaceable resources. No Case-specific drawing recipe is selected in TypeScript.
The same Library / Profile / Scenario model is shown with changed input Questions and selected evidence, using one program and one hand-drawn style:
Adopter Question · Maintainer Question · Selected source gap. The source gap is an observed declaration, not issued evidence or an accepted capture. Selection reasons and input fingerprints remain attached to the exported receipt; changed inputs require selection and rendering again.
Editable D2 · Selection, licensing and acceptance.
This repository follows REUSE with SPDX comment headers, file-specific notices, and standard sidecars for binary and strict JSON files. See licensing and rendering asset attribution.