# BRIK64 Documentation Official BRIK64 documentation for the current public CLI beta, Digital Circuitality, PCD, monomers, EVA composition, agents, local evidence, releases and public integration surfaces. Source: https://docs.brik64.com/introduction Section: Documentation / Start # Introduction AI can generate code faster than teams can review it. That speed is useful, but it creates a new problem: critical software can spread through products, workflows, agents and infrastructure before anyone can clearly explain what the logic does, where it came from, or what evidence supports it. BRIK64 is trust infrastructure for software logic. It helps developers and AI agents turn critical logic into explicit circuit blueprints, compose those blueprints with a shared vocabulary, and attach local evidence to the inspected scope. The discipline behind BRIK64 is **Digital Circuitality**: the idea that important software should be shaped more like inspectable circuitry than open-ended prose or hidden framework behavior. Inputs should be named. Operations should be finite. Composition should be visible. Evidence should travel with the artifact. BRIK64 does not ask teams to stop using AI, modern frameworks, or existing languages. It gives critical logic a stricter intermediate path before it becomes production code: describe the logic, select the atomic operations, show the composition, create local evidence, and keep the boundary clear. It gives developers and AI agents a shared vocabulary for turning requirements into bounded artifacts: ```text requirement -> PCD -> monomers -> EVA composition -> Polymer -> evidence ``` The public beta workflow starts locally. Use the `brik64` command to initialize project metadata, inspect PCD files, create local evidence for declared scope, and emit candidate outputs for supported targets. Agent instructions are handled through the public skills repository or a supported host agent environment. ## Why BRIK64 Exists Conventional software often hides important behavior inside unbounded functions, implicit control flow, framework side effects, and test suites that only sample execution paths. AI makes this harder: it can produce plausible code quickly, but plausible code is not the same as governable logic. BRIK64 pushes critical logic into a circuit-shaped representation: - requirements become bounded Program Circuit Descriptions (PCD); - monomers provide the atomic operation vocabulary; - EVA makes sequential, conditional and parallel composition explicit; - Polymers group reviewed circuit blueprints into larger units; - `.brik` workspace metadata keeps local decisions and evidence references traceable. The result is not a marketing label. It is an engineering workflow for making logic easier to review, reproduce, compare and govern under a declared scope. ## Where BRIK64 Can Matter BRIK64 is most useful when software behavior is too important to leave as a black box: - financial workflows, pricing, risk scoring and settlement logic; - healthcare, insurance and regulated decision flows; - supply chain, identity, access and compliance automation; - AI-agent workflows where generated actions need clearer boundaries; - migration projects where teams need to understand critical logic before moving it; - safety-sensitive product logic where reviewability matters as much as speed. The current public beta focuses on the local CLI workflow and the documentation needed to use it. Stronger platform, cloud, SDK or certification workflows are documented only when the public release surface supports them. ## Core Principles BRIK64 is built around a small set of principles: | Principle | Meaning | | --- | --- | | Atomicity | Use named monomers instead of hiding behavior inside ad hoc code. | | Composition | Make the structure of logic visible through EVA and Polymers. | | Determinism | Keep behavior bounded where the declared scope requires it. | | Traceability | Preserve decisions, evidence references and local project state. | | Portability | Describe logic before binding it to a specific output target. | | Evidence | Treat local outputs as review artifacts with explicit scope. | These principles are the reason BRIK64 documentation is written for both humans and AI agents. A human should be able to inspect the logic. An agent should be able to follow the same vocabulary without inventing private shortcuts. ## What To Read First - [Quickstart](/quickstart): run the local CLI flow. - [What Is BRIK64?](/what-is-brik64): understand the system model. - [PCD Tutorial](/language/pcd-tutorial): write a circuit description. - [Monomer Catalog](/monomers/catalog): inspect the operation vocabulary. - [Generation Overview](/agents/generation-overview): guide AI agents through BRIK64 authoring. ## Current Availability The public documentation describes BRIK64 CLI and the concepts needed to use it. Hosted platform features, paid cloud execution, SDK install surfaces, and stronger evidence workflows are documented only when their release evidence and access model are available. --- Source: https://docs.brik64.com/what-is-brik64 Section: Documentation / Start # What Is BRIK64? BRIK64 is a way to make software logic easier to inspect. It turns bounded requirements into circuit-shaped blueprints so developers and AI agents can review what the logic does before it spreads across systems. The core model is: ```text Monomer -> PCD Blueprint -> Polymer -> Application/System topology ``` Each layer has a specific job: | Layer | Role | | --- | --- | | Monomer | Atomic operation vocabulary. | | PCD Blueprint | Circuit description for bounded logic. | | EVA | Composition model for sequential, conditional and parallel structure. | | Polymer | Composed logic built from one or more PCDs. | | `.brik` | Local traceability workspace for decisions, events and evidence references. | | CLI | Local command surface for the current public beta PCD workflow. | | Skill | Managed agent instructions installed only with explicit consent. | ## Digital Circuitality Digital Circuitality is the engineering discipline behind BRIK64. It treats software as something that should be shaped like circuitry: bounded inputs, finite operations, explicit composition, deterministic behavior where the scope declares it, and evidence that can be inspected later. For users, this means BRIK64 is not just another code-generation layer. It is a way to make an AI agent or developer explain the logic it is creating: 1. What are the inputs and outputs? 2. Which atomic operations are needed? 3. How are operations composed? 4. What artifacts prove what happened? 5. Which parts are available today and which require future platform support? ## Local-First Product Model The local CLI path is the default because it keeps source and iteration close to the developer. Agents can use BRIK64 without requiring login for the local flow. Managed `AGENTS.md` instructions should only be written through an explicit, reviewable user-approved action. --- Source: https://docs.brik64.com/current-availability Section: Documentation / Start # Current Availability BRIK64 is published as a CLI-first developer workflow. The current public beta gives developers and AI agents a local way to work with PCD files, create scoped local evidence, and emit outputs for supported targets. ## Available Today BRIK64 CLI `0.1.0-beta.18.2` is the current public local beta. The official command is `brik64`. Verify the live installer output with `brik64 --version` before treating any environment as updated. | Surface | Current public status | | --- | --- | | Current version | [`0.1.0-beta.18.2`](https://github.com/brik64/brik64-cli/releases/tag/v0.1.0-beta.18.2). | | Release notes | [GitHub Releases](https://github.com/brik64/brik64-cli/releases/tag/v0.1.0-beta.18.2) | | Install path | `curl -fsSL https://brik64.com/cli/install.sh \| bash` | | Release manifest | `https://brik64.com/cli/releases/0.1.0-beta.18.2.json`; verify live installer output until then. | | Public scope | Local CLI workflow for PCD files, local evidence, and output generation. | | Agent skill | Available through the public [BRIK64 skills repository](https://github.com/brik64/brik64-tools-skills) or a supported host agent environment. | Use `brik64 --version` and `brik64 help` after installation to verify the installed package. The local workflow is centered on the `brik64` command: ```bash brik64 help brik64 version brik64 --version brik64 init brik64 certify brik64 verify brik64 emit brik64 polymerize --out polymer.pcd brik64 migrate --out migrated.pcd brik64 doctor --json brik64 emit --target ts --out out-ts --tests brik64 emit --target rust --out out-rust --tests brik64 emit --target python --out out-python --tests ``` Agent instructions are installed only through explicit consent. The current public beta uses the public skills repository or the host agent environment for agent instructions. `brik64 init` prepares a BRIK64 workspace. It does not create or modify `AGENTS.md`. ## Platform Status | Platform | Status | | --- | --- | | macOS | Available in beta through the portable Node.js CLI package. | | Linux | Available in beta through the portable Node.js CLI package. | | Windows x64 | Not published in beta. | ## Updates There is no silent auto-update path in the public local workflow. Re-run the installer, release manifest and GitHub Release page to verify the current beta package. ## Platform Features Hosted collaboration, cloud execution, paid entitlements, billing-backed features, and stronger evidence workflows require dedicated platform support. Public CLI documentation must not imply that those features are active unless the page links to current release evidence. ## Platform Support The public docs currently target the local CLI flow and portable source-level concepts. Platform-specific binary support is documented only when a release artifact has been verified. --- Source: https://docs.brik64.com/quickstart Section: Documentation / Start # Quickstart AI can generate code faster than teams can review it. BRIK64 helps turn critical logic into inspectable blueprints and local evidence artifacts. This guide runs the current BRIK64 CLI beta local workflow. It does not require login for local use. ## 0. Install The CLI The current public CLI beta is installed through the public installer. Verify the executable after install with `brik64 --version` and `brik64 help`. Install: ```bash curl -fsSL https://brik64.com/cli/install.sh | bash ``` Check [Install the BRIK64 CLI](/cli/install) for release links, package checksums and platform status. The installer, release manifest and GitHub Releases page are the public release surfaces. ## 1. Inspect The CLI ```bash brik64 help brik64 version brik64 --version ``` `brik64 help` should print the installed command surface plus links to docs, the public skill repository and the PCD standard. ## 2. Run The Developer Assurance Loop ```bash brik64 init --profile startup --structure modular brik64 audit . --out .brik/audit --json ``` Read `.brik/audit/BRIK64_AUDIT_REPORT.md`, `.brik/audit/audit-results.json`, and `.brik/audit/blueprint/blueprint-report.json` when present. The report mode tells you what the CLI produced: - `pcd_certified`: local PCD candidates and a local polymer exist. - `sdk_logic`: use BRIK64 SDK-first for the identified logic modules. - `inspection_draft`: treat the result as an inspection map only. If the installed CLI does not expose `audit`, use the lower-level blueprint command and record the version drift in the report: ```bash brik64 blueprint . --out brik64-blueprint --mermaid --evidence --json ``` `brik64 init` prepares local BRIK64 project metadata. It does not create or modify `AGENTS.md`. ## 3. Create Or Choose A PCD Create a `.pcd` file from a bounded requirement or use a reviewed local PCD candidate. PCD means Program Circuit Description. Treat it as a circuit description for bounded logic, not as a free-form script. ## 4. Create Local Evidence ```bash brik64 explain path/to/program.pcd --suggest --fix-plan --json brik64 certify path/to/program.pcd brik64 test path/to/program.pcd --generate-scenarios --json ``` The command creates local evidence for the inspected scope. Treat the output as an artifact for review, not as a broad application-wide statement. ## 5. Emit A Local Candidate Output ```bash brik64 emit path/to/program.pcd brik64 emit path/to/program.pcd --target ts --out out-ts --tests ``` Use the generated files and tests as local candidate artifacts. They are not release certificates. ## 6. Use The Agent Skill With Consent Install or read the official skill through the public skills repository or your host agent environment: ```text https://github.com/brik64/brik64-tools-skills ``` Any `AGENTS.md` write must be explicit, reviewable and user-approved. --- Source: https://docs.brik64.com/concepts/terms Section: Documentation / Start # Terms ## BRIK64 A CLI-first system for designing software logic as explicit circuit structure. ## Digital Circuitality The discipline of shaping software as bounded, compositional, deterministic and inspectable computational circuitry. ## PCD Program Circuit Description. A PCD describes bounded logic as a circuit blueprint. ## `.pcd` The source artifact for a PCD Blueprint. It can be raw source or an envelope that carries non-semantic metadata around exact `pcd_source` bytes. ## Monomer An atomic BRIK64 operation. Monomers are the operation vocabulary used when expressing circuit logic. ## EVA The BRIK64 composition model: sequential, conditional and parallel structure. ## Polymer A composed unit built from PCDs and lower-level operations. ## `.brik` The local BRIK64 workspace for traceability, logic events, export records and evidence references. ## BIR BRIK64 intermediate representation below PCD, used by analysis and generation workflows. ## TCE Thermodynamic Coherence Engine. In public docs, treat TCE as an evidence and coherence mechanism under a declared scope. ## Evidence Pack A collection of artifacts, hashes, reports, manifests and references that support a bounded engineering statement. ## Evidence Status The explicit statement of what an artifact currently supports and what remains outside the available evidence. ## Managed Section The delimited section in `AGENTS.md` used for reviewed BRIK64 agent instructions. The current CLI beta does not expose `brik64 skill` subcommands. ## Agent Skill BRIK64 instructions for coding agents. The skill helps agents generate PCD, select monomers, preserve `.brik` traceability and avoid unsupported claims. ## CLI The local `brik` command surface. ## MCP Model Context Protocol integration for exposing BRIK64 context and workflows to AI agents. --- Source: https://docs.brik64.com/cli Section: Documentation / CLI # BRIK64 CLI `brik64` is the official public command surface for BRIK64. Use it to create local project metadata, inspect the installed beta surface, create local evidence for `.pcd` files, and emit candidate outputs under the current public beta scope. ## Current Public Beta BRIK64 CLI `0.1.0-beta.18.2` is the current public beta surface. Use the installed CLI and the release notes page to identify the exact version currently installed. | Surface | Current public value | | --- | --- | | Version | [`0.1.0-beta.18.2`](https://github.com/brik64/brik64-cli/releases/tag/v0.1.0-beta.18.2) | | Command | `brik64` | | Compatibility aliases | `brik` | | Release notes | [GitHub Releases](https://github.com/brik64/brik64-cli/releases) | | Install | `curl -fsSL https://brik64.com/cli/install.sh \| bash` | See [Install the BRIK64 CLI](/cli/install) before using any package-manager command or direct artifact. ## Install And Verify After installing a release that is explicitly listed on the install page, verify the command surface: ```bash brik64 help brik64 version brik64 --version ``` ## Command Families - Help and version: `brik64 help`, `brik64 version`, `brik64 --version` - Project setup: `brik64 init` - Local candidate evidence: `brik64 certify ` - Local candidate output: `brik64 emit ` - Target examples: `brik64 emit --target ts|rust|python --out --tests` - Diagnostics: `brik64 explain `, `brik64 doctor`, `brik64 errors status` - Local lockfile: `brik64 lock` - Privacy controls: `brik64 telemetry status`, `brik64 telemetry explain`, `brik64 feedback --dry-run` Generation, polymerization, update, engine, and skill-management command families are part of the public beta surface only when the installed CLI help lists them. Local CLI artifacts support inspection and review under their stated scope. Stronger platform claims require the corresponding release evidence. --- Source: https://docs.brik64.com/cli/install Section: Documentation / CLI # Install the BRIK64 CLI BRIK64 CLI `0.1.0-beta.18.2` is the current public local beta. The official command is `brik64`. Always verify the installed version. Install with the public installer: ```bash curl -fsSL https://brik64.com/cli/install.sh | bash ``` Verify the installed command: ```bash brik64 --version brik64 help ``` The compatibility alias `brik` is installed for existing workflows: ```bash brik --version ``` Use `brik64` in new documentation, scripts and agent instructions. ## Release Record | Field | Current value | | --- | --- | | Version | `0.1.0-beta.18.2` | | Release tag | [`v0.1.0-beta.18.2`](https://github.com/brik64/brik64-cli/releases/tag/v0.1.0-beta.18.2) | | Manifest | `https://brik64.com/cli/releases/0.1.0-beta.18.2.json` | | Official docs | `https://docs.brik64.com/cli/install` | | Installer | `https://brik64.com/cli/install.sh` | ## Platform Status | Platform | Status | Public note | | --- | --- | --- | | macOS | Available in beta | Portable Node.js CLI package; requires Node.js 20 or newer. | | Linux | Available in beta | Portable Node.js CLI package; requires Node.js 20 or newer. | | Windows x64 | Not published in beta | No beta Windows ZIP or executable claim is published. | ## Package Checksums Use the release manifest or `SHA256SUMS` from the release record when validating direct artifacts. | Artifact | SHA-256 | | --- | --- | | `brik64-cli-0.1.0-beta.18.2.tgz` | Check the release manifest or `SHA256SUMS` from the Beta18.2 release record. | ## Current Beta Scope The Beta18.2 CLI is for local BRIK64 workflows: project initialization profiles, PCD inspection with suggestions and fix plans, native bounded scenario testing, semantic PCD diff, blueprint documentation, static policy hygiene lint, aggregate local audit reports, local verification, local polymerization, legacy PCD migration, local evidence for declared scope, typed PCD emission for supported syntax, target scaffolding and release artifact verification. Developer assurance loop: ```bash brik64 init --profile startup --structure modular brik64 audit . --out .brik/audit --json ``` The current also supports local source lift preview: ```bash brik64 lift js src/pricing.js --preview brik64 lift ts src/pricing.ts --preview brik64 lift python src/pricing.py --preview brik64 adoption report --json ``` Source lift preview generates local PCD candidates and warning reports under `.brik/lift-preview/`. It does not create certificates, does not upload source, and does not assert full translation coverage. Hosted platform features and additional platform packages appear in release notes when they are available for public use. npm is used for the JS/TS SDK package `@brik64/core`; it is not the CLI install channel. --- Source: https://docs.brik64.com/cli/commands Section: Documentation / CLI # Commands This page lists the command surface documented for the current public CLI beta. Always confirm against the installed package with `brik64 help`. ## Core ```bash brik64 help brik64 --version brik64 init --profile startup --structure modular brik64 doctor --json brik64 engine status --json ``` ## Developer Assurance Loop ```bash brik64 audit . --out .brik/audit --json brik64 explain pcd/add.pcd --suggest --fix-plan --json brik64 test pcd/add.pcd --generate-scenarios --json brik64 diff pcd/v1/add.pcd pcd/v2/add.pcd --impact --json brik64 doc pcd/add.pcd --format markdown --out docs/brik64 --json brik64 lint-policy . --policy all --json ``` `audit` aggregates blueprint generation, doctor, ledger, policy lint and PCD diagnostics into a local evidence bundle. Policy lint is static hygiene only; it is not compliance certification. ## Blueprint And Lift ```bash brik64 blueprint . --out brik64-blueprint --mermaid --evidence --json brik64 lift ts path/to/file.ts --preview --json brik64 adoption report --json ``` `blueprint` creates a scoped local report. `lift` creates local preview candidates and warning reports. Neither command claims whole-application proof. ## PCD Workflow ```bash brik64 template --type numeric-monomer --out pcd/add.pcd brik64 certify pcd/add.pcd brik64 verify pcd/add.pcd --json brik64 emit pcd/add.pcd --target ts --out out-ts --tests brik64 polymerize pcd/add.pcd --out pcd/polymers/core.polymer.pcd --json ``` Generated files and tests are local candidate artifacts. Review them before use. ## Traceability And Privacy ```bash brik64 lock --files pcd/add.pcd --json brik64 ledger status brik64 telemetry status brik64 telemetry explain brik64 feedback --category docs --message "local feedback" brik64 errors status ``` Telemetry is opt-in. Local reports must not include raw private source, secrets, tokens, or whole-application proof claims. ## Updates And Skills ```bash brik64 update --check --json brik64 skill check-version --json brik64 monomers list --json brik64 monomers explain MC_00.ADD8 --json ``` Use package managers for SDKs only. The CLI install channel is the public curl installer and GitHub Release asset. --- Source: https://docs.brik64.com/cli/blueprint Section: Documentation / CLI # Blueprint `brik64 blueprint` inspects a repository locally and writes a scoped evidence bundle for review. In Beta18.2 it reports one of three modes so agents do not overstate what happened: - `pcd_certified`: local PCD candidates and a local polymer were generated. - `sdk_logic`: logic was mapped for BRIK64 SDK-first adoption. - `inspection_draft`: the command produced an inspection map only. ```bash brik64 blueprint . --out brik64-blueprint --mermaid --evidence --json ``` For routine repository adoption in Beta18.2, prefer the aggregate assurance loop: ```bash brik64 init --profile startup --structure modular brik64 audit . --out .brik/audit --json ``` `audit` calls the blueprint workflow as one evidence layer and also records doctor, ledger, policy lint, and PCD explain diagnostics. The command writes: ```text brik64-blueprint/BRIK64_BLUEPRINT_PLAN.md brik64-blueprint/system-blueprint.md brik64-blueprint/BRIK64_AUDIT_REPORT.md brik64-blueprint/architecture-map.mmd brik64-blueprint/operation-coverage.json brik64-blueprint/unsupported-logic.json brik64-blueprint/pcd-inventory.csv brik64-blueprint/sdk-logic-modules.json ``` ## What It Means - `blueprint-report.json` records `mode`, `blueprintSource` and count fields such as `certifiedPcdCount`, `polymerCount` and `sdkLogicModules`. - `operation-coverage.json` lists operation families observed in source files. - `unsupported-logic.json` lists logic that was not converted into scoped PCD candidates or SDK-first modules. - `pcd-inventory.csv` is non-empty only when local PCD candidates were emitted. - `sdk-logic-modules.json` lists modules that should be handled through BRIK64 SDKs instead of PCD in the current beta. - Mermaid output is a visual explanation, not a proof artifact. - The report is local and does not upload private source. ## Claim Boundary `brik64 blueprint` is a scoped local workflow. `pcd_certified` means local candidate evidence exists for generated PCD/polymer artifacts. `sdk_logic` and `inspection_draft` are review modes, not PCD certification. None of these modes claim whole-application proof, compliance certification, fixpoint, self-hosting, or formal correctness. --- Source: https://docs.brik64.com/cli/init Section: Documentation / CLI # Init `brik64 init` creates local BRIK64 state for a project. ```bash brik64 init ``` Expected output: ```text created=.brik/manifest.json ``` ## Writes ```text .brik/manifest.json ``` ## Does Not Write ```text AGENTS.md ``` The current CLI beta does not expose `brik64 skill` subcommands. Install or read the official skill through [brik64/brik64-tools-skills](https://github.com/brik64/brik64-tools-skills) or your host agent environment, and write `AGENTS.md` only with explicit review and user consent. --- Source: https://docs.brik64.com/cli/pcd-generate Section: Documentation / CLI # PCD Generate PCD generation commands are documented when the installed CLI help and release notes list them. The current public workflow can still use this page as a model for reviewing generated PCD candidates. ```bash brik64 pcd generate order-risk ``` ## Before Generation State the requirement in bounded form: ```text Approve an order only when amount and limit are positive and amount does not exceed limit. ``` ## After Generation Review: - generated file path; - circuit name; - inputs and output; - fail-closed cases; - monomers used; - external behavior, if any. Generation starts the circuit workflow when the installed CLI supports it. It does not remove the need for review. --- Source: https://docs.brik64.com/cli/certify Section: Documentation / CLI # Certify `brik64 certify` creates local evidence records for generated PCD files. ```bash brik64 certify path/to/program.pcd ``` ## When To Run Run `brik64 certify` after generating or editing a PCD candidate and before composing it into a Polymer. ## Expected Sample Files ```text certificates/order_risk.core.cert.json certificates/order_risk.extended.cert.json ``` The exact filenames can vary by release and project. Inspect the actual output paths created by your local command. ## What To Review - Which PCD was inspected? - Which command created the evidence file? - Which version of the CLI ran? - Which hash or manifest identifies the artifact? - What scope does the output cover? Local evidence records support review of the inspected files. They do not replace source review, release evidence or platform authorization. --- Source: https://docs.brik64.com/cli/polymerize Section: Documentation / CLI # Polymerize Polymerization commands are documented when the installed CLI help and release notes list them. Conceptually, polymerization composes reviewed PCD candidates into a larger logic unit. ```bash brik64 polymerize ``` ## When To Run Run it after: - PCD candidates exist; - local evidence has been created or reviewed; - dependencies are ready to compose; - the agent can explain the EVA structure. ## Expected Sample File ```text polymer/order_risk.polymer.pcd ``` ## Review Focus - Which PCD candidates were included? - Which dependency changed? - Is the Polymer stale or current? - Which evidence status applies to the composed result? ## Common Mistake Do not treat a Polymer as stronger than its inputs. If a PCD is only a local candidate, the Polymer remains a local candidate too. --- Source: https://docs.brik64.com/cli/compile-test Section: Documentation / CLI # Compile And Test The current public local workflow uses `brik64 emit ` for candidate outputs. Generate a local candidate output: ```bash brik64 emit path/to/program.pcd ``` Generate target examples when your installed CLI help lists the target: ```bash brik64 emit path/to/program.pcd --target ts --out out-ts --tests ``` ## What To Inspect - Which files were generated. - Which target languages were emitted. - Which local checks or generated tests are present. - Which report files changed. - Which command version ran. Passing checks are regression evidence for the documented sample flow. Pair them with the command, version and files involved. --- Source: https://docs.brik64.com/cli/doctor Section: Documentation / CLI # Doctor Use `brik64 help` and `brik64 --version` as the current beta checks. If your installed CLI lists `brik64 doctor`, it can provide environment diagnostics. ```bash brik64 doctor ``` ## What Doctor Should Surface - CLI version. - Documentation URL. - Current working directory. - Local workspace status. - Update mode. - Managed-section status. - Missing prerequisites. - Recommended next command. ## When It Helps Environment diagnostics are useful when: - the project has no visible BRIK64 state; - a command fails due to missing files; - update metadata is unclear; - `AGENTS.md` contains an existing managed section; - local workspace status is unclear. --- Source: https://docs.brik64.com/cli/troubleshooting Section: Documentation / CLI # Troubleshooting ## Start With Help And Version ```bash brik64 help brik64 --version ``` Record the command output before changing files. ## Skill Conflicts Preview changes before writing `AGENTS.md`: ```text Use the public skills repository or host agent environment to preview the managed instructions before any AGENTS.md write. ``` ## Update Problems The current public beta update path is the public installer plus the GitHub Release page. There is no silent auto-update path in the public local workflow. --- Source: https://docs.brik64.com/agents Section: Documentation / Build With Agents # Agents BRIK64 docs are written for humans and AI agents. Use the official public agent skill from [brik64/brik64-tools-skills](https://github.com/brik64/brik64-tools-skills) when working with the CLI, `.brik`, PCD 1.0, local evidence, or managed `AGENTS.md` instructions. Before important work, agents should check this documentation and the public skills repository so local instructions do not drift from current public guidance. The agent rule is simple: ```text Do not start by writing code. Start by shaping the requirement into a bounded circuit. ``` ## Agent Flow ```text requirement -> inputs and outputs -> fail-closed behavior -> monomer selection -> PCD Blueprint -> EVA structure -> Polymer candidate -> .brik traceability -> local evidence -> bounded report ``` ## Required Behavior - Read the current repo state before editing. - Explain the requirement as inputs and outputs. - Select monomers from the catalog. - Keep EVA structure explicit. - Preview managed instructions from the public skills repository or host agent environment before any `AGENTS.md` write. - Check https://docs.brik64.com and the public skills repository periodically during long-running work. - Report commands run and files changed. - State evidence status without inflating the result. Use these pages to generate BRIK64 artifacts without inventing unsupported syntax, command flags or public statements. --- Source: https://docs.brik64.com/agents/generation-overview Section: Documentation / Build With Agents # Generation Overview An AI agent using BRIK64 should behave like a circuit designer. The goal is not to produce the most code. The goal is to produce the clearest bounded artifact that a human can inspect and a tool can trace. ## Required Flow 1. Restate the requirement in bounded language. 2. Name inputs, outputs and blocked cases. 3. Select monomers from the catalog. 4. Write PCD with explicit branches and returns. 5. Explain EVA composition in source structure or topology metadata. 6. Create a Polymer only after the PCD candidate exists. 7. Preserve `.brik` traceability. 8. Run local CLI checks. 9. Report evidence status and remaining assumptions. ## Example Agent Trace ```text Requirement: approve orders under a configured limit. Inputs: amount, limit. Output: 1 approve, 0 block. Blocked cases: non-positive amount, non-positive limit, amount > limit. Monomers: comparison/control in PCD; no extended monomers needed. Composition: conditional gate followed by explicit return. Evidence: local CLI output after generation and checks. ``` ## What Agents Must Avoid - Do not modify `AGENTS.md` through `brik64 init`. - Do not write outside the managed BRIK64 section unless the user asks. - Do not invent monomer names. - Do not treat local evidence as a broad application claim. - Do not describe future hosted features as active local behavior. - Do not expose PCD, Polymer, monomer, DTL, ledger, certification or internal engine vocabulary in ordinary end-user frontend copy. Use domain language such as bounded logic, domain rule, validation contract, local trace or review state. ## Handoff Format When an agent finishes a BRIK64 change, report: ```text Requirement: Inputs: Output: Fail-closed behavior: Monomers used: EVA structure: Files changed: CLI checks run: Evidence status: Open assumptions: ``` --- Source: https://docs.brik64.com/agents/from-requirement-to-pcd Section: Documentation / Build With Agents # From Requirement To PCD Agents should convert prose into bounded circuit behavior before writing PCD. ## Template ```text Requirement: Inputs: Output: Blocked cases: Allowed cases: Monomers: EVA structure: Evidence status: ``` ## Example ```text Requirement: approve an order under a configured limit. Inputs: amount, limit. Output: 1 approve, 0 block. Blocked cases: amount <= 0, limit <= 0, amount > limit. Allowed cases: amount > 0 and amount <= limit. Monomers: no extended monomers required. EVA structure: conditional gate. Evidence status: local candidate after CLI checks. ``` Then write PCD with explicit branches and returns. --- Source: https://docs.brik64.com/agents/monomer-selection Section: Documentation / Build With Agents # Monomer Selection Use a core-first discipline when selecting monomers. ```text Try MC_00..MC_63 first. Use MC_64..MC_127 only when behavior cannot be expressed cleanly with core monomers. ``` ## Selection Steps 1. Identify the smallest operation needed. 2. Check whether a core monomer expresses it. 3. Prefer ordinary PCD control flow for branches. 4. Add extended monomer comments when extended behavior is required. 5. Do not invent helper functions or monomer names. ## Extended Candidate Comment ```pcd // certification-profile: extended_contract // extended-monomers: MC_64 required for contract-bound float adapter ``` Extended monomer use creates a review item. It does not authorize a stronger public claim. --- Source: https://docs.brik64.com/agents/eva-composition Section: Documentation / Build With Agents # EVA Composition For Agents Agents should explain EVA as source structure and data flow. ## Three Forms | Form | Meaning | What the explanation should make visible | | --- | --- | --- | | Sequential | One value feeds the next. | The intermediate value is named and consumed. | | Conditional | A branch selects the result. | Every branch returns a compatible result. | | Parallel | Independent branches run separately. | Branches do not depend on shared intermediate state. | ## Sequential Example ```pcd return MC_00.ADD8(amount, fee); ``` ## Conditional Example ```pcd if (amount <= 0) { return 0; } return 1; ``` ## Parallel Explanation Represent independent values explicitly: ```pcd return MC_00.ADD8(left, right); ``` ## Workflow Note Use symbolic EVA notation only in explanatory prose. Executable examples should use the documented PCD shape for the release being described. In Beta14.1, direct PCD monomer calls are limited to the numeric parser profile. --- Source: https://docs.brik64.com/agents/pcd-authoring-rules Section: Documentation / Build With Agents # PCD Authoring Rules Write PCD that a human can review as a circuit. ## Required Shape ```pcd PC example { fn evaluate(input) { if (input <= 0) { return 0; } return 1; } } ``` ## Rules - Start with `PC `. - Use explicit functions. - Name inputs in plain language. - Return from every path. - Keep fail-closed behavior visible. - Use catalog monomer names only. - Avoid invented dialect features. - Explain external behavior before using extended monomers. ## Review Before Reporting ```text PCD file: Circuit name: Inputs: Output: Fail-closed behavior: Monomers: EVA structure: Evidence status: ``` If any item is unknown, report it as unknown instead of filling it in from assumption. --- Source: https://docs.brik64.com/agents/brik-workspace-rules Section: Documentation / Build With Agents # .brik Workspace Rules `.brik/` is the project-local BRIK64 logic workspace. It records: - project metadata; - decisions; - evidence references; - local update plans; - traceability links. It does not: - certify PCD semantics; - change canonical PCD or BIR hashes; - prove repository correctness; - replace evidence packs; - grant public claim authorization. ## Workflow Note If you write or inspect `.brik` metadata, describe it as traceability metadata unless a separate evidence pack supports a stronger bounded statement. --- Source: https://docs.brik64.com/agents/validation-checklist Section: Documentation / Build With Agents # Validation Checklist Before treating a local result as ready for review, verify: - Requirement is bounded. - Inputs and outputs are explicit. - Fail-closed behavior is explicit. - PCD follows active syntax. - No helper functions or monomers were invented. - Extended monomer use is justified. - EVA is represented as supported structure. - `.brik` is treated as metadata. - CLI commands were run or clearly marked unrun. - Evidence status is stated. - End-user frontend copy uses domain language instead of PCD, Polymer, monomer, DTL, ledger, certification, engine-tier or internal release vocabulary unless the UI is explicitly an expert developer console. ## Minimum Local Flow ```bash brik64 init brik64 certify path/to/program.pcd brik64 emit path/to/program.pcd ``` Use generation, polymerization, compile, test, update, engine, or skill subcommands only when the installed CLI help and current release evidence show they are available. If a command was not run, say so. --- Source: https://docs.brik64.com/agents/anti-patterns Section: Documentation / Build With Agents # Anti-Patterns BRIK64 agent work fails when the artifact becomes harder to inspect. Avoid these patterns. ## Invented Vocabulary Do not invent monomer names, file standards, command flags or evidence labels. Use the documented catalog and CLI reference. ## Hidden Behavior Do not hide important behavior in helper functions without explaining the circuit role. If the helper is necessary, explain its inputs, output and failure behavior. ## Open Branches Do not omit blocked cases or return different result kinds from different branches. ## Unsupported Syntax Do not write typed-argument syntax, arrow returns or symbolic EVA expressions as executable PCD unless the release documentation supports that syntax. ## Unauthorized Agent Writes Do not modify `AGENTS.md` through `brik64 init`. Use the public skill repository or host agent environment and require explicit review before writing: ```text https://github.com/brik64/brik64-tools-skills ``` ## Overstated Results Do not use local checks as broad application claims. Pair results with command output, files changed and evidence status. ## Internal Vocabulary In Product UI Do not expose PCD, Polymer, monomer, DTL, ledger, certification or engine-tier language in ordinary user-facing frontend copy unless the page is explicitly an expert developer console. Translate internal BRIK64 terms into product-domain language: | Internal term | User-facing language | | --- | --- | | PCD | bounded logic, domain rule, validation contract, review artifact | | ledger / DTL | local trace, trace history, audit trail, review state | | certified / secured | checked, validated for this scope, traceable | | Polymer | composed rule set, system rule set | Raw PCD names, hashes, `.brik` paths and command output belong in expandable developer diagnostics, logs, reports or agent-readable evidence, not in primary application labels. --- Source: https://docs.brik64.com/agents/install-skill Section: Documentation / Build With Agents # Use The BRIK64 Skill The official public BRIK64 agent skill is maintained in [brik64/brik64-tools-skills](https://github.com/brik64/brik64-tools-skills). Check that repository and https://docs.brik64.com before important agent work, especially when preparing public reports or installing managed instructions. Use the skill through your host agent environment, or review the public repository directly: ```text https://github.com/brik64/brik64-tools-skills ``` Any `AGENTS.md` managed-section write must be explicit, reviewable and user-approved. The managed section is guidance for agents. It is not a certificate for the repository. --- Source: https://docs.brik64.com/agents/managed-section Section: Documentation / Build With Agents # Managed Section When BRIK64 managed instructions are installed into `AGENTS.md`, they should live only inside explicit markers: ```text ... ``` The section hash protects the managed body from silent drift. ## Rules - Text outside the markers belongs to the user. - `brik64 init` does not create these markers. - Skill installation should happen through the host agent environment or by reviewing the public `brik64-tools-skills` repository. - Any `AGENTS.md` write must be explicit, reviewable and user-approved. If markers or hash validation fail, preview the intended managed section before repairing. --- Source: https://docs.brik64.com/agents/conflicts Section: Documentation / Build With Agents # Conflicts Managed-section conflicts happen when markers are duplicated, incomplete or hash mismatched. ## Recovery Flow 1. Preview the intended managed section from the public skills repository or the host agent environment. 2. Review local edits inside the managed section. 3. Move user-owned content outside the managed markers. 4. Update or remove the managed section only after explicit review. Do not manually edit marker syntax unless you are intentionally repairing the managed boundary. --- Source: https://docs.brik64.com/language Section: Documentation / Language & Composition # Language PCD is the BRIK64 language for describing bounded logic as a circuit. The public authoring profile is intentionally compact. It gives agents enough structure to produce inspectable logic without inventing a broad dialect. The public standards repository for the PCD file and programming baseline is [brik64/pcd-standard](https://github.com/brik64/pcd-standard). The public `.brik` workspace standard is [brik64/brik-standard](https://github.com/brik64/brik-standard). ## Core Shape ```pcd PC example { fn evaluate(input) { if (input <= 0) { return 0; } return 1; } } ``` ## Authoring Guidance - Name the circuit with `PC`. - Declare functions with explicit inputs. - Use `if` branches with explicit returns. - Use bounded loops when needed. - Call monomers from the catalog. - Return a defined value from every path. - Explain external behavior before using extended monomers. ## Reading Path 1. [PCD Tutorial](/language/pcd-tutorial) 2. [PCD Syntax](/language/pcd-syntax) 3. [PCD File Standard](/language/pcd-file-standard) 4. [.brik Workspace](/language/brik-workspace) 5. [Examples](/language/examples) 6. [Errors](/language/errors) ## Agent Output Every agent-authored PCD should be accompanied by: ```text Requirement: Inputs: Output: Fail-closed behavior: Monomers: EVA structure: Evidence status: ``` --- Source: https://docs.brik64.com/language/pcd-tutorial Section: Documentation / Language & Composition # PCD Tutorial PCD means Program Circuit Description. A PCD is not a general script; it is a circuit blueprint for bounded logic. This tutorial builds an `order_risk` circuit. ## 1. Start With A Bounded Requirement Do not start from implementation. Start from behavior: ```text Approve an order only when: - amount is positive - limit is positive - amount does not exceed limit Otherwise block the order. ``` ## 2. Declare Inputs And Output ```text inputs: - amount - limit output: - 1 means approve - 0 means block ``` ## 3. Declare Fail-Closed Behavior ```text amount <= 0 -> 0 limit <= 0 -> 0 amount > limit -> 0 otherwise -> 1 ``` This is the circuit contract an agent must preserve. ## 4. Write The PCD ```pcd PC order_risk { fn evaluate(amount, limit) { if (amount <= 0) { return 0; } if (limit <= 0) { return 0; } if (amount > limit) { return 0; } return 1; } } ``` The structure matters: - every branch returns a defined value; - negative or zero inputs block; - the approval path is the final path; - no external state is required. ## 5. Generate The Starter Candidate `brik64 pcd generate order-risk` is available only in generation-capable builds. For the current public CLI beta, create or review a `.pcd` file manually unless `brik64 help` lists the generation command. Review generated output before composing it into a Polymer. Generation is not a substitute for reviewing the declared inputs, outputs and fail-closed behavior. ## 6. Use Supported Numeric Monomers When The Operation Is Atomic For public CLI Beta14.1 PCD files, direct monomer calls are limited to the numeric parser profile: `MC_00.ADD8`, `MC_01.SUB8`, `MC_02.MUL8`, `MC_03.DIV8`, and `MC_04.MOD8`. ```pcd PC add8_gate { fn add8_gate(a: i64, b: i64) -> i64 { return MC_00.ADD8(a, b); } } ``` String and extended monomer helpers remain SDK-level examples or roadmap syntax until the PCD parser exposes those operations publicly. ## 7. Agent Checklist - The requirement is restated in bounded form. - Inputs and output are named. - Fail-closed behavior is explicit. - Every branch returns a value. - Monomers are selected from the catalog. - Extended or external behavior is identified before composition. - The PCD can be reviewed without hidden source context. --- Source: https://docs.brik64.com/language/pcd-syntax Section: Documentation / Language & Composition # PCD Syntax Use a conservative PCD shape for public examples. ```pcd PC example { fn evaluate(input) { if (input <= 0) { return 0; } return 1; } } ``` ## Rules - Start with `PC `. - Keep functions explicit. - Return a value from every branch. - Use monomer calls from the catalog. - Avoid unsupported symbolic syntax in executable examples. - Keep external behavior visible in the surrounding explanation. --- Source: https://docs.brik64.com/language/pcd-file-standard Section: Documentation / Language & Composition # PCD File Standard PCD means Program Circuit Description. Raw `.pcd` source is the human-readable circuit description. The public standards repository is [brik64/pcd-standard](https://github.com/brik64/pcd-standard). It publishes the PCD File Standard v1.0, the PCD Programming Standard v1, and the schema files derived from the current `brik64-prod` standards baseline. For distributable or synchronized artifacts, BRIK64 can use a JSON envelope around exact source bytes. ```json { "schemaVersion": "brik64.pcd_file.v1", "pcd_source": "PC example {\\n OUTPUT 1;\\n}\\n", "canonical": { "semantic_pcd_sha256": "sha256:" }, "metadata": {}, "certification_refs": [] } ``` ## Hash Boundary The semantic hash is calculated from exact `pcd_source` bytes. Metadata and certificate references are operational context, not part of the semantic source. ## Metadata Boundary Metadata can describe authorship, source authority and local workflow context. It must not contain secrets, tokens, raw private source snapshots or absolute local paths. ## Editing An Enveloped PCD When editing an enveloped PCD: 1. Update `pcd_source` intentionally. 2. Recompute or request recomputation of `semantic_pcd_sha256`. 3. Preserve metadata only when it remains true. 4. Record the command that produced the new artifact. ## Public Boundary The PCD standard defines file shape, metadata, canonical hash boundaries and compiler-bound authoring rules. It is not itself a compiler release, certificate, runtime artifact or evidence pack. --- Source: https://docs.brik64.com/language/brik-workspace Section: Documentation / Language & Composition # .brik Workspace `.brik` stores local BRIK64 project metadata. In Beta15.6, the CLI also writes selected workspace events to `.brik/ledger/` so local activity can be checked as a tamper-evident hash chain. The public `.brik` workspace standard is published at [brik64/brik-standard](https://github.com/brik64/brik-standard). ## Typical Records - Logic events. - Ledger events in `.brik/ledger/events.jsonl`. - Ledger head pointer in `.brik/ledger/head.json`. - Export references. - Local decisions. - Evidence references. - Command metadata. - Generated artifact references. ## What Belongs In `.brik` Use `.brik` for operational metadata that helps explain what happened: ```text event: command: input artifact: output artifact: hash: timestamp: evidence status: ``` ## What Does Not Belong In `.brik` Do not store: - secrets; - tokens; - raw private source snapshots; - unrelated personal data; - private account identifiers; - credentials or API keys. `.brik` helps preserve traceability. It does not replace review of the PCD, Polymer or command output. ## Ledger Commands Use the ledger commands to inspect local workspace history: ```bash brik64 ledger status brik64 ledger verify --json brik64 ledger export --redacted brik64 ledger tombstone --reason "superseded by follow-up evidence" ``` Ledger verification fails closed when events are edited, deleted, reordered or when required ledger files are missing from an initialized workspace. The local ledger is not a distributed blockchain and is not a formal certificate. It is local tamper-evident workspace history. --- Source: https://docs.brik64.com/language/examples Section: Documentation / Language & Composition # Examples ## Order Gate ```pcd PC order_gate { fn order_gate(amount, limit) { if (amount <= 0) { return 0; } if (limit <= 0) { return 0; } if (amount > limit) { return 0; } return 1; } } ``` ## Numeric Monomer ```pcd PC add8_gate { fn add8_gate(a: i64, b: i64) -> i64 { return MC_00.ADD8(a, b); } } ``` String monomer helpers such as concat and length are SDK-level examples in the current public beta. The CLI PCD parser supports the documented numeric monomer profile first. --- Source: https://docs.brik64.com/language/errors Section: Documentation / Language & Composition # Errors BRIK64 commands should fail clearly when required files, markers, manifests or hashes are missing. ## What To Report Agents should report: - command run; - working directory; - files expected; - files found; - exact error text; - recovery command, if available; - evidence status after the failure. ## Example Report ```text Command: host-agent skill install for AGENTS.md Status: failed Expected: managed-section markers Found: conflicting manual section Recovery: preview the managed section from brik64-tools-skills and review conflict Evidence status: no managed section was written ``` ## Fail-Closed Behavior If a command cannot verify a manifest, marker, hash or target file, the agent should stop and report the missing condition instead of inventing a result. When an error affects release status, include the exact artifact and command that failed. --- Source: https://docs.brik64.com/monomers Section: Documentation / Language & Composition # Monomers Monomers are atomic BRIK64 operations used to express bounded circuit logic. They are the vocabulary agents should use when turning requirements into PCD. ## Core-First Guidance ```text Core-first. Extended only when necessary and explicitly justified. ``` ## How To Use This Section 1. Read [Core And Extended Monomers](/monomers/core-vs-extended). 2. Use [Monomer Tutorial](/monomers/tutorial) for examples. 3. Use [Selection Guide](/monomers/selection-guide) before generating PCD. 4. Inspect [Monomer Catalog](/monomers/catalog) for IDs and names. ## Agent Questions - Which operation is needed? - Does a core monomer express it? - Is external behavior involved? - Which family does the monomer belong to? - How will the result be composed through EVA? Do not invent helpers when a catalog monomer expresses the operation clearly. --- Source: https://docs.brik64.com/monomers/tutorial Section: Documentation / Language & Composition # Monomer Tutorial A monomer is the smallest named operation in the BRIK64 vocabulary. Agents should use monomers to make logic explicit instead of hiding behavior in ad hoc helper code. ## Selection Flow 1. Identify the operation in plain language. 2. Search the [Monomer Catalog](/monomers/catalog). 3. Prefer core monomers when they express the operation. 4. Use extended monomers only when the behavior crosses into external or specialized domains. 5. Record any external dependency before composing the PCD. ## Numeric PCD Example ```pcd PC byte_total { fn byte_total(a: i64, b: i64) -> i64 { return MC_00.ADD8(a, b); } } ``` This circuit uses: | Monomer | Purpose | | --- | --- | | `MC_00.ADD8` | Add two bounded numeric inputs. | ## SDK-Level String Example String helpers such as concat and length are available as SDK concepts, but are not direct PCD parser calls in the current public CLI beta. Keep them in SDK examples until the release notes list string PCD parser support. ```pcd // Roadmap / SDK-level concept, not current CLI PCD syntax: // MC_40.CONCAT(prefix, code) // MC_43.LEN(label) ``` Review the relevant release and catalog before relying on detailed arithmetic behavior. Public docs list the vocabulary; precise semantics belong to the compiler-facing source and evidence for the release. ## Agent Checklist - The monomer exists in the catalog. - The family matches the intended behavior. - The PCD keeps control flow explicit. - Extended behavior is recorded before composition. - The final explanation names each monomer used. --- Source: https://docs.brik64.com/monomers/selection-guide Section: Documentation / Language & Composition # Selection Guide ## Core-First Selection Use core monomers before extended monomers. ```text MC_00..MC_63 -> preferred default MC_64..MC_127 -> extended contract candidate ``` ## Questions - Can ordinary PCD arithmetic or branching express this? - Is a core monomer available? - Does extended behavior introduce external contracts? - Can the behavior be bounded with simpler inputs? - Is the monomer name and arity documented? If the answer is unclear, do not invent a monomer. Mark the candidate as needing review. --- Source: https://docs.brik64.com/monomers/core-vs-extended Section: Documentation / Language & Composition # Core And Extended Monomers BRIK64 uses two public monomer ranges. | Range | Meaning | | --- | --- | | `MC_00..MC_63` | Core operation vocabulary. | | `MC_64..MC_127` | Extended operation vocabulary for specialized or external domains. | ## Core Monomers Core monomers should be the first choice for ordinary arithmetic, logic, memory, control, I/O, string, crypto and system-shaped operations. ## Extended Monomers Extended monomers are useful when the behavior crosses into specialized domains such as float math, network, graphics, audio, filesystem extensions, concurrency or interop. ## Selection Guidance When extended monomers appear in a PCD, document why a core monomer was insufficient. ```text Extended monomer: Reason: External boundary: Evidence status: ``` --- Source: https://docs.brik64.com/monomers/catalog Section: Documentation / Language & Composition # Monomer Catalog This catalog lists the public BRIK64 monomer vocabulary used by the current documentation. It records IDs, names, families, short operational descriptions and available signatures from the structured repository catalog. Source used for this public table: the BRIK64 monomer catalog used by this documentation. The descriptions below are selection guidance for humans and AI agents. Detailed preconditions, postconditions, memory effects, error behavior and runtime contracts require reconciliation across the compiler-facing sources before they are published as normative semantics. Current CLI Beta14.1 direct PCD parser support is narrower than this vocabulary: numeric examples may use `MC_00.ADD8`, `MC_01.SUB8`, `MC_02.MUL8`, `MC_03.DIV8`, and `MC_04.MOD8`. Other catalog entries are vocabulary, SDK-level helpers, or roadmap parser surface until a release note says otherwise. ## Core Monomers ### Arithmetic | ID | Name | Description | Signature | | --- | --- | --- | --- | | MC_00 | ADD8 | Add two 8-bit unsigned values. Use for bounded byte arithmetic where overflow behavior must be handled by the active runtime contract. | `(u8, u8) -> u8` | | MC_01 | SUB8 | Subtract one 8-bit unsigned value from another. Use for byte-level difference logic with explicit underflow handling at the surrounding PCD boundary. | `(u8, u8) -> u8` | | MC_02 | MUL8 | Multiply two 8-bit unsigned values. Use for bounded byte multiplication when truncation or overflow handling is made explicit by the selected contract. | `(u8, u8) -> u8` | | MC_03 | DIV8 | Divide one 8-bit unsigned value by another and expose quotient plus remainder-shaped output. Use only when division-by-zero handling is specified outside the name alone. | `(u8, u8) -> (u8, u8)` | | MC_04 | INC | Increment an 8-bit unsigned value by one. Use for counters, loop state or small bounded state transitions. | `(u8) -> u8` | | MC_05 | DEC | Decrement an 8-bit unsigned value by one. Use for countdowns, bounded retries or reverse iteration state. | `(u8) -> u8` | | MC_06 | MOD8 | Return the 8-bit remainder from byte-sized division. Use for wrap, bucket or residue logic with explicit zero-divisor handling. | `(u8, u8) -> u8` | | MC_07 | NEG8 | Produce the byte-level negation form for an 8-bit value under the active arithmetic contract. Use when signed intent or two's-complement interpretation is documented by the PCD. | `(u8) -> u8` | ### Logic | ID | Name | Description | Signature | | --- | --- | --- | --- | | MC_08 | AND8 | Apply bitwise AND to two 8-bit values. Use for masks, flags and byte-level gating. | `(u8, u8) -> u8` | | MC_09 | OR8 | Apply bitwise OR to two 8-bit values. Use for setting flags or merging byte masks. | `(u8, u8) -> u8` | | MC_10 | XOR8 | Apply bitwise XOR to two 8-bit values. Use for toggles, parity-shaped checks or reversible byte transforms. | `(u8, u8) -> u8` | | MC_11 | NOT8 | Invert all bits in one 8-bit value. Use for complement masks and byte-level negation of flags. | `(u8) -> u8` | | MC_12 | SHL8 | Shift an 8-bit value left by a provided amount. Use when bit positions move toward more significant bits. | `(u8, u8) -> u8` | | MC_13 | SHR8 | Shift an 8-bit value right by a provided amount. Use when bit positions move toward less significant bits. | `(u8, u8) -> u8` | | MC_14 | ROL8 | Rotate an 8-bit value left by a provided amount. Use when shifted-out bits must re-enter on the opposite side. | `(u8, u8) -> u8` | | MC_15 | ROR8 | Rotate an 8-bit value right by a provided amount. Use when right-shifted bits must wrap around. | `(u8, u8) -> u8` | ### Memory | ID | Name | Description | Signature | | --- | --- | --- | --- | | MC_16 | LOAD | Read a value from a declared memory location or runtime state slot. Use only with an explicit address/source contract. | `runtime contract` | | MC_17 | STORE | Write a value to a declared memory location or runtime state slot. Use only when mutation scope is explicit. | `runtime contract` | | MC_18 | PUSH | Push a value onto a stack-like runtime structure. Use for ordered temporary state where stack discipline is part of the PCD. | `runtime contract` | | MC_19 | POP | Remove and return the top value from a stack-like runtime structure. Use with explicit empty-stack behavior. | `runtime contract` | | MC_20 | PEEK | Inspect the top or selected stack value without removing it. Use when read-only stack access is needed. | `runtime contract` | | MC_21 | SWAP | Exchange the order of two stack or register-like values. Use to make dataflow ordering explicit without hidden temporaries. | `runtime contract` | | MC_22 | DUP | Duplicate a stack or runtime value. Use when one value must feed multiple later operations. | `runtime contract` | | MC_23 | DROP | Discard a stack or runtime value. Use to make intentional value disposal explicit. | `runtime contract` | ### Control | ID | Name | Description | Signature | | --- | --- | --- | --- | | MC_24 | JMP | Transfer control to a declared target. Use for explicit branch edges, not implicit flow. | `runtime contract` | | MC_25 | LOOP | Represent bounded or contract-defined repetition. Use only when loop bounds or stop conditions are specified. | `runtime contract` | | MC_26 | CALL | Invoke a declared PCD, polymer or runtime callable boundary. Use when inputs, outputs and side effects are named. | `runtime contract` | | MC_27 | RET | Return from a declared callable boundary. Use to make output handoff and control return explicit. | `runtime contract` | | MC_28 | IF | Select a branch based on a declared condition. Use for explicit conditional logic with named true/false paths. | `runtime contract` | | MC_29 | HALT | Stop execution for the current circuit or runtime lane. Use for terminal states and fail-closed exits. | `runtime contract` | | MC_30 | NOP | Perform no state-changing operation. Use as an explicit placeholder, alignment point or trace marker. | `runtime contract` | | MC_31 | WAIT | Pause until a declared condition, event or time boundary. Use only when the wait contract is bounded or externally specified. | `runtime contract` | ### I/O | ID | Name | Description | Signature | | --- | --- | --- | --- | | MC_32 | READ | Read bytes, records or values from a declared I/O source. Use with explicit source and failure behavior. | `runtime contract` | | MC_33 | WRITE | Write bytes, records or values to a declared I/O sink. Use with explicit sink and acknowledgement behavior. | `runtime contract` | | MC_34 | PRINT | Emit human-readable output through a declared text channel. Use for display/log-like output, not hidden state. | `runtime contract` | | MC_35 | INPUT | Receive external input through a declared channel. Use only when validation and trust boundary are documented. | `runtime contract` | | MC_36 | OPEN | Open a declared resource handle. Use with explicit resource type, mode and failure contract. | `runtime contract` | | MC_37 | CLOSE | Close a declared resource handle. Use to make lifecycle release explicit. | `runtime contract` | | MC_38 | SEEK | Move a cursor or offset inside a declared stream/resource. Use when random access is part of the contract. | `runtime contract` | | MC_39 | FLUSH | Force buffered output or state to the declared sink. Use when durability or ordering boundary matters. | `runtime contract` | ### Strings | ID | Name | Description | Signature | | --- | --- | --- | --- | | MC_40 | CONCAT | Combine strings or byte-text segments in declared order. Use when concatenation is the intended operation. | `runtime contract` | | MC_41 | SPLIT | Divide text by a declared delimiter or rule. Use with explicit delimiter, max parts and empty-field behavior when relevant. | `runtime contract` | | MC_42 | SUBSTR | Extract a substring by declared position or range. Use with explicit indexing and out-of-range behavior. | `runtime contract` | | MC_43 | LEN | Measure string or buffer length. Use when downstream logic depends on explicit size. | `runtime contract` | | MC_44 | UPPER | Convert text to uppercase under the declared locale/encoding contract. Use for normalization where casing matters. | `runtime contract` | | MC_45 | LOWER | Convert text to lowercase under the declared locale/encoding contract. Use for normalization where casing matters. | `runtime contract` | | MC_46 | TRIM | Remove declared leading/trailing characters or whitespace. Use for input cleanup with explicit trim set. | `runtime contract` | | MC_47 | MATCH | Test text against a declared pattern or matcher. Use with explicit pattern semantics and match result shape. | `runtime contract` | ### Crypto | ID | Name | Description | Signature | | --- | --- | --- | --- | | MC_48 | HASH | Compute a declared hash over declared input bytes. Use only with algorithm and encoding identified by the surrounding contract. | `runtime contract` | | MC_49 | ENCRYPT | Encrypt declared data using a declared key/material boundary. Use with explicit algorithm, mode and failure handling. | `runtime contract` | | MC_50 | DECRYPT | Decrypt declared data using a declared key/material boundary. Use with explicit algorithm, mode and authentication behavior. | `runtime contract` | | MC_51 | SIGN | Produce a signature over declared data. Use with explicit key identity, algorithm and message representation. | `runtime contract` | | MC_52 | VERIFY | Check a signature, proof-shaped artifact or authenticity marker under a declared crypto contract. Use with explicit pass/fail behavior. | `runtime contract` | | MC_53 | DIGEST | Produce or handle a digest value as a named artifact. Use when the digest itself is the dataflow output. | `runtime contract` | | MC_54 | KEY | Create, load, derive or reference key material under a declared key-management boundary. Use without exposing secrets. | `runtime contract` | | MC_55 | RNG | Request random or pseudo-random data from a declared source. Use with explicit entropy/source assumptions. | `runtime contract` | ### System | ID | Name | Description | Signature | | --- | --- | --- | --- | | MC_56 | TIME | Read a declared time source or timestamp. Use with explicit clock and determinism assumptions. | `runtime contract` | | MC_57 | CPU | Inspect or request CPU-related runtime information. Use only when host dependency is an explicit boundary. | `runtime contract` | | MC_58 | MEM | Inspect or request memory-related runtime information. Use only when host/resource dependency is explicit. | `runtime contract` | | MC_59 | GETENV | Read an environment variable or environment-like setting. Use with explicit variable name and missing-value behavior. | `runtime contract` | | MC_60 | EXIT | End the process or runtime lane with a declared status. Use for explicit terminal outcomes. | `runtime contract` | | MC_61 | PID | Read process identity from the host/runtime. Use when process identity is an explicit external dependency. | `runtime contract` | | MC_62 | LOG | Emit structured or textual runtime log output. Use for traceability without treating logs as certification. | `runtime contract` | | MC_63 | ASSERT | Check a declared invariant and fail according to the active contract when it is false. Use for explicit guard conditions. | `runtime contract` | ## Extended Monomers ### Float64 | ID | Name | Description | Signature | | --- | --- | --- | --- | | MC_64 | FADD | Add floating-point values under the declared float64 contract. Use only when integer monomers do not express the requirement. | `runtime contract` | | MC_65 | FSUB | Subtract floating-point values under the declared float64 contract. Use with explicit rounding and exceptional-value assumptions. | `runtime contract` | | MC_66 | FMUL | Multiply floating-point values under the declared float64 contract. Use with explicit precision and exceptional-value assumptions. | `runtime contract` | | MC_67 | FDIV | Divide floating-point values under the declared float64 contract. Use with explicit zero, infinity and NaN handling. | `runtime contract` | | MC_68 | FABS | Return the absolute value of a floating-point value. Use when sign removal is the intended float operation. | `runtime contract` | | MC_69 | FNEG | Negate a floating-point value. Use when sign inversion is the intended float operation. | `runtime contract` | | MC_70 | FSQRT | Compute a floating-point square root. Use with explicit domain and exceptional-value handling. | `runtime contract` | | MC_71 | FMOD | Compute a floating-point remainder. Use with explicit divisor and exceptional-value handling. | `runtime contract` | ### Math | ID | Name | Description | Signature | | --- | --- | --- | --- | | MC_72 | SIN | Compute sine under the declared math/float contract. Use for trigonometric behavior with explicit unit assumptions. | `runtime contract` | | MC_73 | COS | Compute cosine under the declared math/float contract. Use for trigonometric behavior with explicit unit assumptions. | `runtime contract` | | MC_74 | TAN | Compute tangent under the declared math/float contract. Use with explicit handling near undefined points. | `runtime contract` | | MC_75 | EXP | Compute exponential growth under the declared math contract. Use with explicit range and overflow assumptions. | `runtime contract` | | MC_76 | LN | Compute natural logarithm. Use with explicit positive-domain and exceptional-value handling. | `runtime contract` | | MC_77 | LOG2 | Compute base-2 logarithm. Use with explicit positive-domain and exceptional-value handling. | `runtime contract` | | MC_78 | POW | Raise a value to a declared power. Use with explicit domain, exponent and exceptional-value behavior. | `runtime contract` | | MC_79 | CEIL | Round a numeric value upward to the next integer-shaped boundary. Use with explicit numeric representation. | `runtime contract` | ### Network | ID | Name | Description | Signature | | --- | --- | --- | --- | | MC_80 | NCONNECT | Open a network connection to a declared endpoint. Use with explicit protocol, timeout and failure behavior. | `runtime contract` | | MC_81 | NSEND | Send data through a declared network channel. Use with explicit framing, retry and acknowledgement assumptions. | `runtime contract` | | MC_82 | NRECV | Receive data from a declared network channel. Use with explicit framing, timeout and partial-read behavior. | `runtime contract` | | MC_83 | NCLOSE | Close a declared network channel. Use to make network lifecycle release explicit. | `runtime contract` | | MC_84 | NBIND | Bind a network endpoint or socket. Use with explicit address, port and permission assumptions. | `runtime contract` | | MC_85 | NLISTEN | Listen for inbound network connections. Use with explicit queue, protocol and availability assumptions. | `runtime contract` | | MC_86 | NACCEPT | Accept an inbound network connection. Use with explicit trust boundary and failure handling. | `runtime contract` | | MC_87 | NPOLL | Poll one or more network channels for readiness. Use with explicit timeout and event model. | `runtime contract` | ### Graphics | ID | Name | Description | Signature | | --- | --- | --- | --- | | MC_88 | GPLOT | Plot a point or pixel in a declared graphics surface. Use with explicit coordinate and color model. | `runtime contract` | | MC_89 | GLINE | Draw a line on a declared graphics surface. Use with explicit endpoints, stroke and clipping behavior. | `runtime contract` | | MC_90 | GRECT | Draw a rectangle on a declared graphics surface. Use with explicit bounds, stroke/fill and clipping behavior. | `runtime contract` | | MC_91 | GCIRCLE | Draw a circle on a declared graphics surface. Use with explicit center, radius and clipping behavior. | `runtime contract` | | MC_92 | GFILL | Fill a region or primitive on a declared graphics surface. Use with explicit fill rule and color model. | `runtime contract` | | MC_93 | GTEXT | Render text on a declared graphics surface. Use with explicit font, encoding and positioning assumptions. | `runtime contract` | | MC_94 | GBLIT | Copy image or buffer data into a graphics surface. Use with explicit source, destination and blending behavior. | `runtime contract` | | MC_95 | GCLEAR | Clear a graphics surface or region. Use with explicit target region and clear value. | `runtime contract` | ### Audio | ID | Name | Description | Signature | | --- | --- | --- | --- | | MC_96 | APLAY | Play audio through a declared output channel. Use with explicit format, device and timing assumptions. | `runtime contract` | | MC_97 | AREC | Record audio from a declared input channel. Use with explicit format, device and privacy boundary. | `runtime contract` | | MC_98 | AMIX | Mix multiple audio streams or buffers. Use with explicit channel, gain and clipping behavior. | `runtime contract` | | MC_99 | AGAIN | Apply audio gain. Use with explicit gain scale and clipping behavior. | `runtime contract` | | MC_100 | APAN | Apply stereo or multi-channel pan. Use with explicit channel layout and pan law. | `runtime contract` | | MC_101 | AFILTER | Apply an audio filter. Use with explicit filter type, coefficients or named preset. | `runtime contract` | | MC_102 | AFFT | Transform audio or signal data into frequency-domain representation. Use with explicit windowing and size assumptions. | `runtime contract` | | MC_103 | AIFFT | Transform frequency-domain data back toward time-domain representation. Use with explicit normalization assumptions. | `runtime contract` | ### Filesystem | ID | Name | Description | Signature | | --- | --- | --- | --- | | MC_104 | FSTAT | Read metadata for a declared filesystem path or handle. Use with explicit path boundary and missing-file behavior. | `runtime contract` | | MC_105 | FCHMOD | Change permissions for a declared filesystem path or handle. Use only when permission mutation is an explicit requirement. | `runtime contract` | | MC_106 | FMKDIR | Create a directory at a declared path. Use with explicit parent, permission and existing-path behavior. | `runtime contract` | | MC_107 | FRMDIR | Remove a directory at a declared path. Use with explicit empty/non-empty and failure behavior. | `runtime contract` | | MC_108 | FLIST | List files or entries under a declared path. Use with explicit filtering, ordering and permission assumptions. | `runtime contract` | | MC_109 | FCOPY | Copy a file or filesystem object. Use with explicit source, destination and overwrite behavior. | `runtime contract` | | MC_110 | FMOVE | Move or rename a file or filesystem object. Use with explicit source, destination and overwrite behavior. | `runtime contract` | | MC_111 | FLINK | Create or inspect a filesystem link. Use with explicit link type and target behavior. | `runtime contract` | ### Concurrency | ID | Name | Description | Signature | | --- | --- | --- | --- | | MC_112 | SPAWN | Start a declared concurrent task, process or runtime lane. Use with explicit lifecycle and isolation assumptions. | `runtime contract` | | MC_113 | JOIN | Wait for a declared concurrent task to complete and collect its result/status. Use with explicit timeout and failure behavior. | `runtime contract` | | MC_114 | LOCK | Acquire a declared synchronization lock. Use with explicit scope, ordering and deadlock assumptions. | `runtime contract` | | MC_115 | UNLOCK | Release a declared synchronization lock. Use to make concurrency lifecycle release explicit. | `runtime contract` | | MC_116 | CHAN_SEND | Send a value through a declared channel. Use with explicit buffering, blocking and failure behavior. | `runtime contract` | | MC_117 | CHAN_RECV | Receive a value from a declared channel. Use with explicit blocking, timeout and closed-channel behavior. | `runtime contract` | | MC_118 | ATOMIC_CAS | Perform atomic compare-and-swap. Use with explicit memory ordering and comparison target. | `runtime contract` | | MC_119 | BARRIER | Synchronize multiple tasks at a declared barrier. Use with explicit participant count and timeout/failure behavior. | `runtime contract` | ### Interop | ID | Name | Description | Signature | | --- | --- | --- | --- | | MC_120 | FFI_CALL | Call an external function through a declared foreign interface. Use only when the external boundary is explicitly documented. | `runtime contract` | | MC_121 | FFI_LOAD | Load or bind an external library/symbol. Use with explicit source, symbol name and trust boundary. | `runtime contract` | | MC_122 | FFI_FREE | Release memory or resources allocated through a foreign interface. Use to make external lifecycle cleanup explicit. | `runtime contract` | | MC_123 | FFI_CAST | Convert a foreign value or pointer representation. Use with explicit type and safety assumptions. | `runtime contract` | | MC_124 | FFI_REF | Create or pass a reference into foreign-interface space. Use with explicit ownership and lifetime assumptions. | `runtime contract` | | MC_125 | FFI_DEREF | Read through a foreign reference or pointer. Use with explicit validity, ownership and bounds assumptions. | `runtime contract` | | MC_126 | FFI_ALLOC | Allocate memory or a resource through a foreign interface. Use with explicit size, ownership and cleanup path. | `runtime contract` | | MC_127 | FFI_COPY | Copy data across a foreign-interface boundary. Use with explicit source, destination, length and ownership assumptions. | `runtime contract` | --- Source: https://docs.brik64.com/eva Section: Documentation / Language & Composition # EVA EVA is the BRIK64 composition model for explaining how circuit units connect. It gives agents three structural forms: - sequential flow; - conditional branch selection; - parallel independent branches. ## Why EVA Matters PCD describes operations. EVA explains how those operations compose. Without EVA structure, an agent may generate code that works locally but is hard to inspect as a circuit. ## Public Authoring Guidance In public PCD examples, represent EVA through explicit source structure and topology metadata unless a release documents a supported symbolic syntax. ## Reading Path - [EVA Tutorial](/eva/tutorial) - [Sequential Composition](/eva/sequential) - [Conditional Composition](/eva/conditional) - [Parallel Composition](/eva/parallel) --- Source: https://docs.brik64.com/eva/tutorial Section: Documentation / Language & Composition # EVA Tutorial EVA is the BRIK64 composition model. It gives agents and developers three ways to explain how circuit units connect. | Composition | Meaning | Agent question | | --- | --- | --- | | Sequential | A runs before B and B uses A's output. | What data flows from A to B? | | Conditional | One branch is selected by a condition. | Do all branches return the same kind of result? | | Parallel | Independent branches are evaluated separately. | Are the branches independent? | ## Sequential Sequential composition is the normal pipeline shape. ```pcd PC fee_total { fn fee_total(amount: i64, fee: i64) -> i64 { return MC_00.ADD8(amount, fee); } } ``` The amount and fee inputs feed a named numeric operation. ## Conditional Conditional composition must close every branch. ```pcd PC order_gate { fn order_gate(amount, limit) { if (amount <= 0) { return 0; } if (amount > limit) { return 0; } return 1; } } ``` Every path returns a value, and the blocked paths are explicit. ## Parallel Use parallel composition only when branches are independent. In PCD examples, represent this as separate values that do not mutate shared state. ```pcd PC parallel_summary { fn parallel_summary(left: i64, right: i64) -> i64 { return MC_00.ADD8(left, right); } } ``` ## Authoring Guidance Do not invent symbolic EVA syntax in executable PCD. Use source structure and topology metadata unless a specific compiler release documents a supported symbolic form. --- Source: https://docs.brik64.com/eva/sequential Section: Documentation / Language & Composition # Sequential Composition Sequential composition means one operation feeds the next. ```pcd PC fee_total { fn fee_total(amount: i64, fee: i64) -> i64 { return MC_00.ADD8(amount, fee); } } ``` ## Review Points - The intermediate value is named. - The consumer uses the producer's output. - No hidden global state is needed. - The return value is explicit. ## Review Guidance Keep the data path visible. Beta14.1 executable PCD examples use the public numeric monomer profile; string and crypto monomer flows remain SDK-level or roadmap examples until release notes list parser support. --- Source: https://docs.brik64.com/eva/conditional Section: Documentation / Language & Composition # Conditional Composition Conditional composition selects a branch based on a condition. ```pcd PC gate { fn gate(value) { if (value <= 0) { return 0; } return 1; } } ``` ## Review Points - Blocked cases are explicit. - Every branch returns. - Branches return compatible result kinds. - The final allowed path is visible. ## Review Guidance Every branch must produce a defined result. --- Source: https://docs.brik64.com/eva/parallel Section: Documentation / Language & Composition # Parallel Composition Parallel composition describes independent branches. In public PCD examples, represent parallel work as separate values with no shared mutation: ```pcd PC subtotal { fn subtotal(left: i64, right: i64) -> i64 { return MC_00.ADD8(left, right); } } ``` ## Review Points - Branches use independent inputs. - No branch mutates state needed by another branch. - The merge step is explicit. - The final result is named or returned. ## Review Guidance Only describe branches as parallel when they do not depend on each other's intermediate state. --- Source: https://docs.brik64.com/polymers Section: Documentation / Language & Composition # Polymers A Polymer is a composed unit of BRIK64 logic. It is created after one or more PCD candidates exist and can be inspected. PCD and Polymer are different: | Artifact | Meaning | | --- | --- | | PCD | One circuit blueprint. | | Polymer | A composed unit with dependencies. | | Application/System | A larger topology built from Polymers and integration artifacts. | ## When To Create A Polymer Create or refresh a Polymer when: - a PCD candidate is ready for composition; - dependencies changed; - an agent needs a single composed artifact for review; - a release workflow needs a clear composition unit. ## Local Command Boundary `brik64 polymerize` is not included in the public beta command surface unless `brik64 help` lists it in the installed package. ## Review Checklist - Which PCDs feed the Polymer? - Which monomers appear in the dependency chain? - Which external boundaries remain? - Which command or reviewed authoring step produced the Polymer? - Which local evidence supports the current version? If a dependency changes, treat the Polymer as stale until it is refreshed and reviewed. --- Source: https://docs.brik64.com/polymers/tutorial Section: Documentation / Language & Composition # Polymer Tutorial Generate starter PCDs only when the installed CLI supports generation: `brik64 pcd generate order-risk` is not included in the public beta command surface unless `brik64 help` lists it in the installed package. Create local candidate records: ```bash brik64 certify path/to/program.pcd ``` Compose only when the installed CLI supports polymerization: `brik64 polymerize` is not included in the public beta command surface unless `brik64 help` lists it in the installed package. The Polymer candidate inherits the evidence limits of its dependencies. --- Source: https://docs.brik64.com/composition Section: Documentation / Language & Composition # Composition BRIK64 composition is the process of building larger logic from smaller inspected pieces. The public model is: ```text Monomer -> PCD Blueprint -> Polymer -> Application/System topology ``` ## Layers | Layer | Responsibility | | --- | --- | | Monomer | Atomic operation vocabulary. | | PCD Blueprint | Bounded circuit description. | | EVA structure | The way operations and branches compose. | | Polymer | A composed unit built from PCD candidates and dependencies. | | Application/System topology | The larger graph of Polymers, artifacts and integration boundaries. | ## Failure Propagation Composition is only as strong as its dependencies: ```text invalid PCD -> blocks Polymer refresh stale dependency -> marks Polymer stale missing artifact -> limits evidence status unreviewed generated output -> remains local candidate ``` ## Agent Workflow 1. Build or inspect a PCD first. 2. Identify monomers and external boundaries. 3. Describe EVA structure. 4. Run local checks. 5. Create or refresh a Polymer. 6. Report the evidence status of the composed result. Composition helps expose structure. It should not be used as a shortcut around review, command output or artifact evidence. --- Source: https://docs.brik64.com/composition/topology Section: Documentation / Language & Composition # Topology Topology is the structure of composed BRIK64 logic: which PCDs, monomers and Polymers connect to each other. ## Questions Topology Answers - What depends on what? - Which PCDs are part of the Polymer? - Which monomers appear in the composition? - Which artifacts changed since the last check? - Which evidence status applies to the inspected scope? ## Agent Topology Summary ```text PCDs: Polymers: Monomers: External boundaries: Changed artifacts: Evidence status: ``` ## Use In Reviews Topology is an inspection surface. Pair it with command output, artifact hashes and the relevant source files when using it in a release or audit. Do not infer topology from screenshots alone. Prefer files, reports or command output that can be rerun. --- Source: https://docs.brik64.com/concepts/digital-circuitality Section: Documentation / Concepts # Digital Circuitality Digital Circuitality is the discipline of designing software as closed, inspectable computational circuitry. The central idea is simple: important logic should not depend on hidden paths, unbounded inputs, implicit side effects, or undocumented composition. It should be described through explicit components and explicit routes between those components. ## The Design Principles | Principle | Practical meaning in BRIK64 | | --- | --- | | Bounded domains | Inputs and outputs should be named and constrained. | | Atomic operations | Critical behavior should be decomposed into monomers where possible. | | Explicit composition | Sequential, conditional and parallel structure should be visible. | | Deterministic workflow | The same declared artifact should be reproducible under the stated scope. | | Traceability | Hashes, metadata, events and reports should explain what changed. | | Evidence status | Strong statements must point to artifacts and scope. | ## How It Maps To BRIK64 BRIK64 turns Digital Circuitality into a developer workflow: 1. A requirement becomes a PCD Blueprint. 2. The PCD selects monomers for atomic operations. 3. EVA structure describes how operations compose. 4. A Polymer groups composed logic. 5. `.brik` records local traceability and evidence references. 6. CLI commands generate reports that can be reviewed by humans and agents. ## Theory And Product Digital Circuitality is broader than the CLI. The CLI is the current public product path for applying the discipline locally. The theory pages and papers explain the mathematical direction; the command pages explain what is available in the developer workflow today. Continue with [Theory Papers](/concepts/theory-papers) for source material and [PCD Tutorial](/language/pcd-tutorial) for implementation. --- Source: https://docs.brik64.com/concepts/theory-papers Section: Documentation / Concepts # Theory Papers Digital Circuitality is documented through the public theory site and the paper series authored by Carlos J. Perez. ## Public Theory Sources - [DigitalCircuitality.com](https://digitalcircuitality.com/) - [Carlos J. Perez on Academia](https://ub.academia.edu/CarlosPerez) ## Paper Series | Paper | Reference | | --- | --- | | Digital Circuitality I: The Post-Debt Paradigm | [DOI 10.5281/zenodo.17448329](https://doi.org/10.5281/zenodo.17448329) | | Digital Circuitality II: An Information-Theoretic Framework for Computation | [DOI 10.5281/zenodo.17448474](https://doi.org/10.5281/zenodo.17448474) | | Digital Circuitality III: The Circuit of Coherence | [DOI 10.5281/zenodo.17448562](https://doi.org/10.5281/zenodo.17448562) | | Digital Circuitality IV: The EVA Algebra | [DOI 10.5281/zenodo.17448596](https://doi.org/10.5281/zenodo.17448596) | ## Reading Path Start with the public site for the conceptual overview, then read Paper IV when you need the algebraic background for EVA composition. Use the BRIK64 docs for the current CLI and agent workflow. --- Source: https://docs.brik64.com/concepts/bir Section: Documentation / Concepts # BIR BIR is the intermediate representation below PCD. It is the layer where a circuit description can be normalized for analysis, execution planning and target generation. ## Where BIR Fits ```text PCD source -> parser -> normalized representation -> BIR -> generated artifact ``` PCD is the authoring surface. BIR is not the language an agent should invent by hand unless a task explicitly asks for low-level representation work. ## What BIR Is For - Making generated structure easier to analyze. - Preserving a lower-level representation of the PCD. - Feeding compiler or runtime workflows. - Supporting artifact comparison when hashes and versions are available. ## Agent Guidance Agents should report BIR only when a command produced it or a source file explicitly contains it. Do not infer BIR content from a high-level explanation. When BIR appears in a report, include: ```text PCD source: Command: BIR artifact: Artifact hash: Tool version: Evidence status: ``` ## Evidence Status BIR can support an engineering statement only under a stated inspected scope. A BIR file by itself does not describe the whole project, the runtime environment, or every generated target. --- Source: https://docs.brik64.com/concepts/tce Section: Documentation / Concepts # TCE TCE means Thermodynamic Coherence Engine. In public BRIK64 docs, TCE language should be tied to a specific artifact, command output, release and inspected scope. ## Use TCE Pages To Explain - What was inspected. - Which metrics or reports were produced. - Which version produced them. - Which artifact hash or manifest identifies the output. - What evidence status the result supports. ## Evidence Context TCE-related references should identify the artifact, command, version, metric or report, inspected scope and evidence status. Do not use TCE as a shortcut for broad application correctness. A TCE-related report is meaningful because of the exact scope and artifact it describes. --- Source: https://docs.brik64.com/concepts/proof-trail Section: Documentation / Concepts # Proof Trail Proof Trail is the evidence path behind a BRIK64 statement. It answers: what artifact was inspected, which command produced it, which version ran, which hash identifies the output, and what scope the result covers. ## Typical Trail ```text requirement -> PCD source -> command invocation -> generated artifact -> hash or manifest -> report -> evidence status ``` ## What To Record - Requirement or issue being addressed. - Source files involved. - CLI command and version. - Generated PCD, Polymer or report path. - Hash or manifest path when available. - Human review notes. - Evidence status for the inspected scope. ## Review Context A useful proof trail names the requirement, source, command, output, hash or manifest, evidence status and remaining assumptions. ## Important Boundary A badge, label or filename is not enough. The trail must point to the supporting artifact and explain the scope it covers. --- Source: https://docs.brik64.com/certification Section: Documentation / Concepts # Evidence And Certification BRIK64 uses evidence artifacts to make local work inspectable. `brik64 certify ` is the local command for creating evidence for the inspected PCD scope: ```bash brik64 certify path/to/program.pcd ``` The important question is always: what exact artifact, version, hash, scope and command output support the statement? ## Evidence Status Use evidence status to explain an artifact: | Status | Meaning | | --- | --- | | Local candidate | Generated locally and available for inspection. | | Checked sample | The documented sample flow passed its checks. | | Release-backed | A release artifact documents the command, package or behavior. | | Platform-backed | A hosted workflow documents access, authorization and evidence behavior. | Avoid turning local artifacts into broad application statements. Tie every strong sentence to the artifact and scope that support it. --- Source: https://docs.brik64.com/sdks Section: Documentation / Integrations # SDKs SDKs expose BRIK64 concepts inside language ecosystems. They are useful for examples, teaching monomer behavior and integrating circuit thinking into existing codebases. The CLI remains the primary path for the public local BRIK64 workflow and is distributed through the curl installer. SDK packages are language libraries; they are not CLI installation channels. ## Package Surfaces | Language | Package surface | Current status | Use | | --- | --- | --- | --- | | JavaScript/TypeScript | npm package | `@brik64/core@0.1.0-beta.18.2` | Monomer-oriented helpers and examples. | | Python | PyPI package | `brik64==0.1.0b18` | Monomer helpers and EVA composition examples. | | Rust | crates.io package | `brik64-core@0.1.0-beta.18.2` | Rust monomer helpers and EVA composition examples. | ## Install Commands Use the current beta SDK packages from npm and PyPI. The Rust crate is published on crates.io for Beta18.2: ```bash npm install @brik64/core@0.1.0-beta.18.2 pip install brik64==0.1.0b18 cargo add brik64-core --version 0.1.0-beta.18.2 ``` Do not use npm to install the CLI. Install the CLI with: ```bash curl -fsSL https://brik64.com/cli/install.sh | bash ``` ## Release-Backed Examples Release-backed SDK examples should name the package, installed version, example output and relationship to the local `brik64` command. Treat SDKs as language packages and `brik64` as the command workflow unless the release explicitly says otherwise. --- Source: https://docs.brik64.com/sdks/javascript Section: Documentation / Integrations # JavaScript SDK JavaScript and TypeScript SDK examples use the Beta18.2 beta npm SDK package. ## Install ```bash npm install @brik64/core@0.1.0-beta.18.2 ``` ## Verify The Installed Package ```bash npm ls @brik64/core ``` Use examples only after checking the installed package version against the release notes you are documenting. ## Recommended Example Shape Public examples should be small and inspectable: ```ts import { mc } from "@brik64/core"; const result = mc.add8(10, 20); console.log(result); ``` Before publishing behavior-sensitive examples, run them locally and record the observed output. Arithmetic behavior and monomer coverage should be checked against the package version. --- Source: https://docs.brik64.com/sdks/python Section: Documentation / Integrations # Python SDK The current beta Python SDK is published on PyPI as `brik64==0.1.0b18`. ```bash pip install brik64==0.1.0b18 ``` The Python SDK is a language package for examples, local integration, monomer helpers and EVA composition patterns. It is not the CLI install path. ## Example Policy Python examples should show small, bounded behavior and avoid implying that package installation performs the full CLI workflow. When using Python with BRIK64: - pin `brik64==0.1.0b18` for current beta examples; - keep inputs explicit; - keep outputs explicit; - record package version; - connect the example back to PCD or monomer vocabulary when possible. Package installation only adds the SDK library to your project. CLI commands and workspace workflows use the separate BRIK64 CLI installer. --- Source: https://docs.brik64.com/sdks/rust Section: Documentation / Integrations # Rust SDK The current Rust SDK published on crates.io is `brik64-core@0.1.0-beta.18.2`. ## Verify The Dependency ```bash cargo add brik64-core --version 0.1.0-beta.18.2 cargo tree -i brik64-core ``` ## Library Versus CLI `brik64-core` is a Rust library surface. It should not be documented as the installation method for the local `brik64` command unless a release explicitly provides that path. ## Example Policy Rust examples should: - name the crate version; - keep the function small; - show observed output when behavior matters; - identify related monomers; - avoid replacing CLI evidence with library-only output. Package installation only adds the SDK library to your project. CLI commands and workspace workflows use the separate BRIK64 CLI installer. --- Source: https://docs.brik64.com/integrations/api Section: Documentation / Integrations # API The API surface is for programmatic access to BRIK64 workflows such as project metadata, PCD candidates, topology summaries, evidence references and release metadata. For the current public workflow, local CLI output is the primary integration boundary. API-backed platform features should be documented only when the target deployment provides endpoint, authentication and evidence behavior. ## Integration Model - Use the CLI for local generation, validation, compile, test and update checks. - Use API integrations for hosted review and collaboration only when enabled for the workspace. - Prefer manifests, hashes, PCD candidates, topology summaries and redacted evidence over raw source upload. - Record endpoint, request scope and artifact returned. ## Agent Use Agents should prefer deterministic local commands first. When using an API, they must record: ```text Endpoint: Authentication mode: Input artifact: Returned artifact: Files changed: Evidence status: ``` ## Data Handling Do not assume an API call is private, retained, deleted or billable in a specific way unless the workspace documentation states that behavior. When in doubt, keep source local and use CLI-generated artifacts. --- Source: https://docs.brik64.com/integrations/mcp Section: Documentation / Integrations # MCP MCP integration lets agents discover BRIK64 documentation, command contracts, PCD authoring rules and evidence-oriented workflows through a structured tool surface. The public docs define the behavior expected from an MCP integration. ## Expected Agent Behavior - Read project context before generating PCD. - Prefer monomer selection over ad hoc code generation. - Preserve `.brik` traceability. - Preview managed agent instructions from the public skills repository or host agent environment before any `AGENTS.md` write. - Treat CLI evidence as operational evidence for the inspected scope. ## Recommended MCP Resources An MCP server for BRIK64 should expose: - current CLI command contract; - PCD authoring rules; - monomer catalog; - EVA composition rules; - managed-section marker contract; - update policy; - evidence status vocabulary. ## Agent Handoff ```text MCP resource used: BRIK64 command selected: PCD files changed: AGENTS.md managed section changed: Evidence status: Remaining assumptions: ``` Hosted MCP behavior depends on the workspace where it is enabled. Local CLI behavior remains the default path for private, offline-first work. --- Source: https://docs.brik64.com/community Section: Documentation / Community # Community This page collects public BRIK64 community links and contribution paths. ## Public Entrypoints - GitHub: [github.com/brik64](https://github.com/brik64) - Main site: [brik64.com](https://brik64.com) - Documentation: [docs.brik64.com](https://docs.brik64.com) ## What To Use Each Channel For | Channel | Use | | --- | --- | | GitHub | Public issues, docs corrections and repository discussions where enabled. | | Main site | Product and company entrypoint. | | Documentation | CLI, PCD, monomers, EVA, agents, SDKs and release guidance. | Discord and other community channels should be added only after the official URL is confirmed. ## Public Contribution Guidance Do not post secrets, private repository names, internal evidence paths or unreleased infrastructure details in public channels. --- Source: https://docs.brik64.com/community/discord Section: Documentation / Community # Discord The Discord community link will be published here when the official invite URL is available. Until then, use: - [GitHub](/community/github) - [BRIK64.com](https://brik64.com) - [Security](/community/security) for security reporting guidance ## Status The public Discord channel is not listed yet. Until it is listed, use GitHub for public docs and repository discussion, and use the security reporting path for sensitive issues. --- Source: https://docs.brik64.com/community/github Section: Documentation / Community # GitHub Public GitHub organization: [github.com/brik64](https://github.com/brik64) Use GitHub for public work only when the target repository intentionally exposes issues, discussions or pull requests. ## Good GitHub Issues A useful docs issue includes: - page URL; - current wording; - proposed correction; - evidence source; - whether the change affects CLI, PCD, monomers, EVA, SDKs or release status. ## Avoid - private repo names; - internal evidence paths; - credentials or tokens; - screenshots that expose account data; - unsupported product claims. --- Source: https://docs.brik64.com/community/contributing Section: Documentation / Community # Contributing Public documentation contributions should make BRIK64 easier to understand and safer to use. ## Useful Contributions - Clearer PCD examples. - Better monomer explanations. - Agent workflow improvements. - Glossary corrections. - Release and installation evidence. - Typo and navigation fixes. - Broken link reports. ## Evidence For Wording Changes When proposing wording about evidence, certification, platforms, releases or security, include the artifact or release source that supports the wording. ## Pull Request Checklist ```text Pages changed: Reason: Evidence source: Commands run: Screenshots if visual: Risky terms checked: ``` ## Public Docs Style Prefer direct product language: - what exists; - how to use it; - what evidence is produced; - what the user should inspect next. Avoid internal policy phrasing in public docs. --- Source: https://docs.brik64.com/community/security Section: Documentation / Community # Security Report suspected vulnerabilities, exposed credentials, package compromise or unsafe documentation through the official BRIK64 contact path published on [BRIK64.com](https://brik64.com). Do not include secrets in public issues. ## Useful Security Reports - Affected package, command or page. - Reproduction steps. - Observed output. - Expected behavior. - Whether source, generated artifacts or update manifests are involved. - Whether the issue affects installation, updates, SDK examples, MCP/API behavior or agent instructions. ## Documentation Security Docs issues can be security-relevant when they: - publish unsafe installation instructions; - expose private infrastructure; - suggest uploading source where local artifacts should be used; - overstate release artifact hardening; - instruct agents to write outside managed sections. ## Sensitive Reports If a report contains credentials, tokens, private paths or sensitive account details, stop and move it to the approved private reporting path. --- Source: https://docs.brik64.com/releases Section: Documentation / Releases # BRIK64 Release Notes BRIK64 release notes track what is available, how users should install or update it, and which workflow each release supports. The current public release surface is CLI-first. Install the CLI from the public installer, verify the resolved version locally, and use the GitHub Releases page for the public release record. ## Read First - [Changelog](/releases/changelog) - [Install the BRIK64 CLI](/cli/install) - [Update Policy](/releases/update-policy) - [Channels](/releases/channels) - [Current Availability](/current-availability) ## Current Public Beta BRIK64 CLI `0.1.0-beta.18.2` is the current public beta. Verify `brik64 --version` after install for the active shell. | Surface | Current public value | | --- | --- | | Version | [`0.1.0-beta.18.2`](https://github.com/brik64/brik64-cli/releases/tag/v0.1.0-beta.18.2) | | Official command | `brik64` | | Release notes | [GitHub Releases](https://github.com/brik64/brik64-cli/releases/tag/v0.1.0-beta.18.2) | | Install | `curl -fsSL https://brik64.com/cli/install.sh \| bash` | | Manifest | `https://brik64.com/cli/releases/0.1.0-beta.18.2.json` | The beta channel is for local BRIK64 workflows: project initialization, PCD inspection, SDK-first logic modeling, local evidence for declared scope, and output generation for targets shown by the installed CLI help. ## Release Types | Type | What it means | Where to read | | --- | --- | --- | | CLI beta release | Public local CLI package listed by release tag, manifest and installer. | [Changelog](/releases/changelog) and [GitHub Releases](https://github.com/brik64/brik64-cli/releases/tag/v0.1.0-beta.18.2) | | Documentation release | Public docs, examples, glossary, agent-readable corpus or release guidance changed. | [Changelog](/releases/changelog) | | General release | A future release promoted beyond beta when the public release record says so. | [Channels](/releases/channels) | | Platform/cloud release | Hosted or authenticated features published with their access model. | Release notes for that feature | ## Release Entry Shape Each public release entry should be easy to index: | Field | Purpose | | --- | --- | | Channel | CLI beta, documentation, future general release, or future platform/cloud. | | Date | Publication date for the public note. | | Availability | What users can install, read or use now. | | Changed | Product-level changes, not private implementation notes. | | Update action | The command or reading path users should follow. | | Scope | The public workflow supported by the release. | | Limits | Boundaries that matter for users and agents. | ## Update Model The local update path is the public installer plus the GitHub Releases page. Platform features are documented only when a release provides the access model and evidence behavior. --- Source: https://docs.brik64.com/releases/changelog Section: Documentation / Releases # Changelog This changelog records public product changes for BRIK64. It is organized by release channel so developers, AI agents and operators can understand what changed without reading internal build notes. ## Current Public Beta Date: 2026-07-07. Channel: CLI beta. Version: [`0.1.0-beta.18.2`](https://github.com/brik64/brik64-cli/releases/tag/v0.1.0-beta.18.2). BRIK64 CLI is available through the public curl installer. Install from `https://brik64.com/cli/install.sh`, then use `brik64 --version` and `brik64 help` to verify the exact installed command surface. Install or update: ```bash curl -fsSL https://brik64.com/cli/install.sh | bash ``` Public release links: - [GitHub Release](https://github.com/brik64/brik64-cli/releases/tag/v0.1.0-beta.18.2) - [Install the BRIK64 CLI](/cli/install) ### Changed - Published the current public CLI beta install path. - Aligned the CLI help surface with public docs, the official agent skill repository, and the PCD standard repository. - Documented the local PCD workflow for project initialization, PCD inspection, scoped local evidence and candidate output generation. - Clarified that the public BRIK64 agent skill is distributed through the skills repository or a supported host agent environment. - Kept package, release and docs wording within the public beta claim boundary. ### Supported Scope - Local CLI workflow. - PCD file inspection and local evidence for declared scope. - Candidate output generation for targets shown by the installed CLI help. - Public curl installer and GitHub Release discovery. ### Public Limits - No silent auto-update path. - npm is reserved for release-backed SDK packages; it is not a CLI install channel. - Platform or cloud features are documented only when their public release note lists the access model. - Local CLI output is review evidence for declared scope, not a broad application-level certification statement. ## Documentation Release Date: 2026-06-03. Channel: documentation. ### Changed - Expanded the Introduction so first-time readers can understand BRIK64, Digital Circuitality, the local CLI workflow and the industries where inspectable critical logic matters. - Reworked CLI, install, quickstart, release, SDK, agent and monomer documentation for current public beta wording. - Removed internal build paths, private iteration names, internal artifact hashes and version-discrepancy notes from public pages. - Regenerated the agent-readable documentation index and full corpus from the public pages. - Organized release documentation by current beta, documentation releases, future general releases and future platform/cloud releases. ### Update Action No CLI update is required for documentation-only releases. Refresh the docs page or fetch the current `.md` route when using the agent-readable documentation. ## Future General Releases General releases will be listed here when a public release record promotes a BRIK64 surface beyond beta. Each general release entry will identify the package or artifact, install path, supported scope, update action and public limits. ## Future Platform And Cloud Releases Hosted or authenticated BRIK64 features will be listed here only when their release note describes availability, access model, update behavior and evidence boundaries. --- Source: https://docs.brik64.com/releases/update-policy Section: Documentation / Releases # Update Policy BRIK64 updates are manual in the current public local workflow. This keeps local CLI behavior explicit while the product is in public beta. The public CLI beta is installed through the public installer. Use `brik64 --version` after installation and compare with [GitHub Releases](https://github.com/brik64/brik64-cli/releases) when you need the exact resolved version. Install or update: ```bash curl -fsSL https://brik64.com/cli/install.sh | bash ``` Verify after updating: ```bash brik64 --version brik64 help ``` ## Current Update Model | Surface | Update behavior | | --- | --- | | CLI beta | Manual install or reinstall through `https://brik64.com/cli/install.sh`. | | Release notes | GitHub Releases and this changelog. | | Documentation | Live documentation pages and `.md` routes update through the docs deployment. | | SDK packages | Not a current public update path unless a release note lists the package. | | Platform/cloud features | Updated through their own release note when publicly available. | ## Update Checklist After updating: 1. Run `brik64 --version`. 2. Run `brik64 help`. 3. Confirm the install source used. 4. Check the relevant release note. 5. Re-run the local workflow you depend on. Login is not required for local CLI use. Hosted platform features can require authentication when the specific feature documents that requirement. ## What Changes Later Future release channels may introduce opt-in checks or platform-managed updates. Those behaviors will be documented in [Channels](/releases/channels) before users are expected to rely on them. --- Source: https://docs.brik64.com/releases/channels Section: Documentation / Releases # Channels BRIK64 release channels describe how users receive updates and which product surface each release belongs to. ## Current Channels | Channel | Status | Install or access path | Notes | | --- | --- | --- | --- | | CLI beta | Current public CLI channel | `curl -fsSL https://brik64.com/cli/install.sh \| bash` | Manual local install and update. | | documentation | Current public docs channel | `https://docs.brik64.com` | Public docs, `.md` pages and agent-readable corpus. | | general release | Future | Not listed yet | Used only when a release note promotes a surface beyond beta. | | platform/cloud | Future | Not listed yet | Used only when a release note describes hosted availability and access model. | ## CLI Beta ```bash curl -fsSL https://brik64.com/cli/install.sh | bash ``` Use this channel for the public local CLI workflow. Verify the resolved version with: ```bash brik64 --version brik64 help ``` Other registries or direct artifacts are not public CLI install channels unless [Install the BRIK64 CLI](/cli/install) lists them. ## Documentation Channel Documentation releases update public guides, command references, language pages, monomer explanations, release notes and agent-readable docs. Documentation updates can happen without a CLI package change. When the CLI package changes, the changelog should link the relevant release note. ## Future General Release Channel General releases will be documented when BRIK64 promotes a package or artifact beyond beta. The release note must state the install path, supported scope, update behavior and public limits. ## Future Platform And Cloud Channels Platform or cloud channels will be documented only when the public release surface includes access model, authentication requirements and update behavior. Login is not required for the current local CLI workflow. Hosted platform features can require login when the specific release note says so. ## Channel Selection Use the channel that matches the surface you are updating: | Need | Use | | --- | --- | | Install or update the CLI beta | CLI beta | | Read the current docs | documentation | | Track product changes | changelog plus GitHub Releases | | Adopt a future general release artifact | general release channel once published | | Use hosted features | platform/cloud channel once published | --- Source: https://docs.brik64.com/security/distribution-hardening Section: Documentation / Security # Distribution Hardening Distribution hardening is the release practice of making public artifacts harder to tamper with, impersonate, or inspect casually without leaving the limits of what release evidence supports. It should be documented with evidence, not slogans. ## Required Evidence For A Public Release - Artifact filename and version. - Artifact hash. - Manifest path. - Signature or verification mechanism when available. - Release channel. - Rollback path. - Hardening method summary. - Known limits. ## Allowed Public Wording ```text Hardening can raise the cost of artifact inspection and tampering under verified limits. ``` ## Avoid - Promising that inspection is impossible. - Promising that artifact analysis cannot happen. - Describing hardening without artifact hashes. - Treating obfuscation as correctness evidence. ## Release Artifact Review A public release note should identify the artifact, version, hash, manifest, signature or verification mechanism when available, release channel, hardening evidence and known limits. ---