Features
Software that works like hardware.
Author or lift code into PCD, check bounds, emit targets, and carry review evidence forward.
Operating Model
From bounded blueprint to reusable certified software
Author or lift into PCD, check bounds, emit targets, and route the review object forward.
Workflow Readout
The product is one bounded operating chain, not unrelated features.
Typical workflow
Fragmented software workflow
Code, tests, migration scripts, and audit artifacts often split across tools.
BRIK-64 workflow
Bounded blueprint and review chain
BRIK64 keeps blueprint, checks, emission, and evidence on one path.
System Handles
Stable counts stay tied to the workflow that follows.
Formal operations
Public PCD story centers on 128 operations.
Compilation targets
One blueprint can emit across documented targets.
Proof files
Proof claims stay tied to documented evidence.
Compiler chain
CLI and PCD feed a bounded compiler pipeline.
Migration workflow
Lifting and transpilation share one review path.
Registry and enterprise handoff
Platform and registry consume review-ready outputs.
Coverage
The overview covers compiler chain, migration path, and review posture.
Compilation and closure
CoverageBounded blueprints move through normalization, checks, and emission.
Migration and transpilation
CoverageExisting logic is lifted, reviewed, and moved across targets.
Platform and audit posture
CoverageReview outputs feed platform and registry without blanket verification claims.
Atomic Catalog
Core and extended monomer matrices
The same interactive matrix used in the home hero is exposed here to inspect bounded core operations and contract-bounded extended operations in one surface.
Certified monomer
ATOMIC BOUNDED OPERATIONS
ADD
Arithmetic
Signature
i64, i64 → i64
Role
Bounded numeric transforms and deterministic arithmetic flow.
Extended monomer
Atomic Contract Operations
FADD
Float64
Signature
f64, f64 → f64
Role
Floating-point operations remain explicit and contract-bounded in the review chain.
[01] COMPILATION
One compiler chain from PCD to 10 targets
The compilation story should explain how one bounded blueprint moves through parsing, normalization, and target emission without turning the page into a catalog of backends.
Explicit target set
Rust
JavaScript
TypeScript
Python
C
C++
Go
COBOL
PHP
JavaEngineering Narrative
Workflow focus
Normalize a bounded PCD blueprint once, then emit it across supported targets through the same compiler chain.
Integration point
CLI and direct PCD authoring enter here; platform and registry consume the emitted outputs and their review state.
Technical buyer
Compiler engineer, platform lead, principal engineer
Evidence outputs
parser independence · canonical pipeline form · byte-identical self-hosting generations · target emission from one blueprint
Compiler Chain
The compiler story is strongest when it stays focused on normalization, target emission, and build-chain consistency instead of broad claims about uniqueness.
Entry format
The bounded blueprint is the single entry point into the compilation chain.
Normalization
The compiler stabilizes computation into one intermediate form before target emission.
Emission set
The normalized blueprint remains the anchor while backends emit the supported target outputs.
Parser independence
The parser is documented as hand-built and dependency-light so the compiler chain stays inspectable from the first step.
Canonical pipeline form
Normalization makes the emitted targets downstream of one stable representation rather than a collection of bespoke transformations.
Self-hosting consistency
The self-compilation fixpoint is used here as evidence that documented generations converge to the same build output.
Compilation Readout
The useful public story is the reviewable chain around the blueprint, not a contest of extreme wording.
Parser and normalization
ReadoutThe overview can state that PCD enters a bounded parser and canonical pipeline without implying that every surrounding tool becomes formally proven.
Fixpoint evidence
ReadoutThe repo-backed fixpoint supports consistency of the documented build chain through byte-identical generations and a stable hash.
Target emission
ReadoutThe same normalized computation is the source of the emitted outputs, which keeps the target story anchored to one blueprint.
Claim boundary
The fixpoint supports consistency of the documented compiler build chain. It does not prove every property of every surrounding toolchain or deployment environment.
[02] VERIFICATION
Closure and verification boundaries
Verification copy should help the reader distinguish what the circuit model closes over from what remains outside the public claim boundary.
Engineering Narrative
Workflow focus
Check bounded inputs, closed paths, and review metadata before the blueprint is emitted or trusted downstream.
Integration point
Compilation emits the readout, badges and hashes carry it forward, and enterprise review consumes it later in the chain.
Technical buyer
Principal engineer, verification lead, safety-minded reviewer
Evidence outputs
closure state · domain completeness review · certification hash · review badge posture
Verification Boundary
Compare review models directly and make the public claim boundary legible in the same block.
Sampled review
Tests explore cases after code exists
Conventional testing lowers uncertainty for the cases exercised, but it does not by itself make the modeled boundary explicit or complete.
Bounded review
Closure is checked against the declared circuit
BRIK-64 makes the declared circuit, its bounded domains, and its review consequences visible before emitted code is carried into later workflows.
Verification Outputs
Verification is useful here when the reader can see what is checked, what metadata remains, and where the guarantee stops.
Closure state
OutputThe circuit model is checked for complete paths and bounded behavior before emission, and that state becomes part of the readout.
Domain review
OutputDeclared ranges and conditions are part of the public story because they define what the circuit is actually allowed to do.
Certification hash
OutputHashes and badges are useful here as review metadata carried with the blueprint, not as a replacement for the claim boundary itself.
Claim boundary
The guarantees apply to the formal circuit representation and its declared domains. They do not extend to every uncontrolled runtime or environment outside that model.
[03] DOMAIN CONSTRAINTS
Bounded domains before runtime
This section should make domain declaration the practical differentiator: teams state allowed ranges and reject invalid states before runtime instead of patching around them later.
Engineering Narrative
Workflow focus
Declare numeric and semantic ranges in the blueprint, propagate them through the circuit, and reject invalid states before emission.
Integration point
PCD carries the declared ranges, the compiler propagates them, and emitted targets inherit the same bounded model.
Technical buyer
Principal engineer, staff engineer, domain owner
Evidence outputs
bounded division · bounded arithmetic · bounded floating behavior · domain-encoded business or physical rules
Declared Domains
The useful story is not that every failure vanishes everywhere; it is that declared domains become part of the compile-time model.
Divisor range
division boundaryA divisor domain can exclude zero structurally so the blueprint states what inputs are valid before emission.
Amounts and probabilities
business ruleAmount, rate, and probability ranges stay readable in the blueprint instead of hiding in defensive runtime checks.
Physical or engineering ranges
declared modelTemperature, speed, and other domain values can be encoded directly in the model so violations fail before deployment.
Bounded domain example
PCD range declaration
domain divisor : Range[1, 100]
domain amount : Range[0.01, 1000000.0]
domain ratio : Range[0.0, 1.0]
input total : Float64[0.01 .. 1000000.0]
input fee : Float64[0.0 .. 100000.0]
input parts : Int32[1 .. 100]
output net_per_part : Float64 =
(total - fee) / partsDeclared Outcomes
The surrounding evidence should talk about bounded computation, not about total elimination of every failure mode everywhere.
Bounded division
EffectThe reader should understand why division depends on declared non-zero inputs rather than on hidden runtime hope.
Bounded arithmetic
EffectRange propagation keeps arithmetic consequences reviewable at the blueprint level before the target language syntax appears.
Domain-encoded rules
EffectBusiness, financial, scientific, or physical limits can live inside the model so violations become compile-time failures when the circuit is declared correctly.
Claim boundary
These guarantees exist when the circuit declares and preserves the relevant domains. They do not imply that unmanaged external code loses all numeric failure modes.
[04] LIFTING
Lift existing logic into a reviewable blueprint
Lifting should read as a migration and review workflow: isolate computational logic, mark contract edges, and preserve a review object before rewrite or replatform work starts.
Engineering Narrative
Workflow focus
Inspect source logic, isolate the computational core, emit a blueprint with contract annotations, and review what was preserved before modernization.
Integration point
The Lifter feeds PCD and the compiler chain, then platform and enterprise workflows consume the resulting review object.
Technical buyer
Migration lead, platform lead, principal engineer
Evidence outputs
source language coverage · purity split · bundle decompilation support · incremental lifting
Lifting Workflow
The lifting story is strongest when it behaves like a four-step review flow instead of a general promise about every file ever written.
Inspect the source
Point the Lifter at a source function or bundle and start from the logic that actually needs review.
Isolate the computational core
Separate bounded computation from database, network, filesystem, and other contract edges.
Emit blueprint and annotations
Generate PCD for the preserved computation and keep contract annotations visible for what remains outside full certification.
Review before modernization
Use the emitted blueprint as the reference object before transpilation, refactoring, or platform changes.
Lifting Readout
This block should stay tied to documented coverage, explicit contract boundaries, and concrete migration steps.
Source coverage
EvidenceThe public story can state 10 documented source languages because the repo uses that number consistently in the lifting narrative.
Project-backed liftability
EvidenceThe documented 211/211 result belongs here as evidence from repo-backed projects, not as a universal guarantee for all codebases.
Contract visibility
EvidenceWhen full certification is not possible, the useful public promise is explicit contract-bounded output rather than hidden loss of context.
Claim boundary
Documented projects have reached 211/211 file liftability in the repo evidence. The section does not generalize that result into a universal guarantee, and emitted blueprints stay explicitly contract-bounded when full certification is not possible.
[05] TRANSPILATION
Move one blueprint across targets
Transpilation should read as a normalized blueprint workflow rather than a sweeping promise that all host behavior remains universally equivalent.
Engineering Narrative
Workflow focus
Lift or author the logic, normalize it once in PCD, emit target-specific code, and review preserved computation at the blueprint level.
Integration point
Lifting or direct PCD authoring feeds this stage; emitted targets and preserved review context then move into platform or enterprise workflows.
Technical buyer
Migration lead, architecture owner, platform lead
Evidence outputs
source/target separation · PCD hub role · equivalence review posture · legacy modernization path
Normalization First
The migration story should compare reviewable normalization against raw language-to-language transformation.
Direct rewrite
Syntax-first migration loses the review anchor
When a system moves directly from one language to another, review often follows syntax and tooling quirks rather than the preserved computation itself.
PCD hub
Normalize once, then emit with the blueprint still visible
BRIK-64 uses PCD as the review anchor so teams can inspect what was preserved before target-specific idioms are emitted.
Emission Workflow
The public story needs a fixed migration sequence, not sweeping equivalence slogans.
Lift or author the logic
Start from existing source or from direct PCD authoring, but keep the bounded computation explicit from the first step.
Normalize once
Use PCD as the stable intermediate form that the rest of the review workflow can inspect.
Emit target code
Target-specific code is emitted from the normalized blueprint rather than from a chain of ad hoc rewrites.
Review preserved behavior
The blueprint remains the review anchor for what was preserved across the move.
Claim boundary
Equivalence language in this block stays tied to the extracted and normalized circuit. It does not extend to unmanaged I/O, host APIs, or external side effects.
[06] PLATFORM
Publish, compose, and review reusable circuits
The platform block should explain how certified outputs move into registry, tooling, and review workflows without duplicating the full platform page or overstating availability.
Engineering Narrative
Workflow focus
Publish reviewable circuits, discover reusable blueprints, and keep proof state visible as the workflow moves into registry and tooling.
Integration point
Compilation and lifting feed this layer; registry, IDE, API, and enterprise review workflows consume its outputs.
Technical buyer
Platform lead, tooling owner, engineering manager
Evidence outputs
registry posture · GitHub App workflow · IDE/LSP surface · API and MCP access
Platform Workflow
The platform story should focus on publish, compose, and review workflows rather than on a flat inventory of badges and integrations.
Registry posture
The platform layer combines reusable circuit publishing with controlled visibility and review state.
Operator access
Human and agent workflows reach the same reviewable blueprint through documented access surfaces.
Workflow handoff
The important story is how proof state survives the handoff into later workflows.
Registry publication
Publish review-ready circuits with metadata that keeps the blueprint legible instead of turning it into a generic package entry.
Composition under review
Compose reusable logic while keeping the review object and its proof state visible to the operator.
Tooling access
IDE, API, and MCP access points all matter here because they carry the same workflow state instead of inventing parallel stories.
Access Points
This section should guide the user into the real product surfaces that already exist in the site and repo.
GitHub and certification workflow
RouteThe page can reference GitHub-triggered review flows where repo evidence already supports them, but it should avoid turning that into an exclusivity claim.
IDE and LSP tooling
RouteEditor support belongs here as a way to keep proof state visible where engineers work, not as an isolated bullet list.
API and MCP access
RouteProgrammatic access matters because the same reviewable blueprint can move through human and agent workflows without leaving the bounded chain.
Claim boundary
This block describes workflow surfaces and integration points. It does not imply that every registry package is already public or that roadmap items are live unless separately verified.
[07] AI NATIVE
Use AI as a bounded producer, not as the proof source
The AI block should explain the external verification loop around generated logic rather than turning the page into model hype or trust-by-association.
Engineering Narrative
Workflow focus
Treat model output as a candidate blueprint, constrain it with policy and compiler checks, then use diagnostics to drive the next repair loop.
Integration point
Agent workflows feed candidate logic into PCD and the compiler; platform and registry surfaces consume the bounded result and its diagnostics.
Technical buyer
AI platform lead, principal engineer, agent workflow owner
Evidence outputs
agent skills · MCP tools · machine-readable output · policy circuits · structured diagnostics
External Verification
The AI story should compare model-first confidence against an external verification loop that stays anchored to the blueprint.
Model-first
Generated output without a bounded review loop
When teams trust the model itself as the source of correctness, review state and failure boundaries stay ambiguous.
Bounded loop
Candidate logic enters an external check and repair workflow
BRIK-64 uses policy circuits, compiler checks, and structured diagnostics so the review object remains outside the model.
Agent Workflow
The useful AI story is the bounded workflow around the model, not the claim that the model becomes trustworthy on its own.
Agent skills and tool access
ReadoutAgent workflows belong here because they show how models enter the bounded product chain through documented skills and tool calls.
Policy circuits
ReadoutPolicy circuits constrain actions and candidate logic outside the prompt, which is the important integration point for public messaging.
Structured diagnostics
ReadoutDiagnostics matter because they make the repair loop operator-readable instead of relying on vague model confidence.
Claim boundary
BRIK-64 constrains and reviews agent-produced logic. It does not make the underlying model trustworthy by default.
[08] ENTERPRISE
Carry verified artifacts into audit and operating review
Enterprise copy should explain identity, audit trails, CI gates, deployment posture, and support without drifting into unsupported certification promises.
Engineering Narrative
Workflow focus
Surround the bounded blueprint with identity, audit, CI, deployment, and support workflows so teams can review how it moved and where it was checked.
Integration point
Platform workflows feed this layer, and enterprise review consumes the resulting blueprint, trace, and status metadata.
Technical buyer
Platform lead, compliance engineering, enterprise architect
Evidence outputs
identity integration · tamper-evident compilation trail · CI status gating · deployment boundary · support posture
Enterprise Review
Enterprise value in this block should be framed as review posture around the blueprint, not as automatic certification language.
Identity
Identity integration matters because access to the review object has to fit existing organizational controls.
Audit trail
Compilation and certification records are useful here when they remain inspectable and attributable.
Deployment posture
Deployment boundaries belong in the enterprise story as operating posture rather than as a sweeping promise.
Identity and access
SSO, SAML, OIDC, and SCIM sit around the blueprint so review access stays within existing organizational identity controls.
Audit and CI posture
Compilation records and CI status checks matter here because they show how a bounded blueprint moved through review.
Deployment and support
On-prem posture and human support belong in the operating story, but they are not substitutes for a formal claim boundary.
Enterprise Scope
The supporting block should talk about standards contexts, audit outputs, and deployment boundaries without upgrading them into certification claims.
Standards context
ContextBRIK-64 supports review and audit workflows with evidence artifacts that teams may map into standards contexts such as SOC2, PCI-DSS, HIPAA, ISO 27001, FDA 21 CFR Part 11, and NIST 800-53.
CI and approval flow
ContextRequired status checks and explicit review steps belong here because they make organizational approval paths readable around the blueprint.
Support boundary
ContextHuman support and deployment posture help teams operate the system, but they do not replace the need to qualify what the system itself does and does not certify.
Claim boundary
BRIK-64 supports review and audit workflows. It does not by itself certify an organization against SOC2, PCI-DSS, HIPAA, ISO 27001, FDA 21 CFR Part 11, or NIST 800-53.
Start locally, then move into platform workflows
Install the CLI to begin from a bounded local workflow, then move the resulting blueprint into platform and registry review paths when the computation is ready to travel.