Entry review
DDC Snapshot
C$15 one-time
A bounded assurance snapshot for one public GitHub repository.
- One public GitHub repository
- Exact repository state resolved before review
- Read-only/static preflight
- Material assurance observations
- Concise digital result and next steps
Typical input: a public GitHub repository URL and the primary question you want DDCAL to challenge.
Not included: private evidence handling, code execution, certification, accreditation, or a comprehensive security audit.
Buy DDC Snapshot
Focused review
Quick Assurance Review
C$69 one-time
A focused DDC review of one eligible repository, AI agent, extension, or small application.
- One defined target
- Scope and boundary review
- Prioritized technical findings
- Remediation guidance
- Concise digital report
Typical input: a public target URL and review question. A small supporting evidence set can be requested after payment when it is relevant to the agreed boundary.
Not included: certification, accreditation, legal advice, penetration testing, or unlimited remediation cycles.
Buy Quick Review
Pre-launch
Pre-Launch Assurance
C$249 one-time
A deeper bounded review for one eligible software or AI system before release or a material transition.
- Architecture and authority-boundary review
- Prioritized findings
- Remediation guidance
- One post-fix verification cycle
- Digital assurance report
Typical input: a defined system, the release/version/commit under review, and the primary claim, invariant, failure condition, or concern you want challenged. Supporting architecture, requirements, configuration, test, or verification evidence can be brought into the agreed scope after intake.
Scope note: unusually large, private, confidential, or complex systems may require a separately agreed evidence-transfer or scope boundary before substantive work begins.
Buy Pre-Launch Assurance
Blockchain & smart-contract assurance
Smart-contract and blockchain work is available as a separately scoped technical assessment rather than being silently forced into one of the three software checkouts.
StaticSmart-contract source review
Public Solidity/EVM source, repository structure, access control, invariants, external-call risk and other bounded static findings. No signing or deployment authority.
On-chainDeployed identity & authority
Read-only inspection of chain ID, contract address, bytecode/source correspondence, proxies, implementations, privileged roles, oracles, bridges and other material dependencies.
Full boundedContract + deployed-state assurance
Source, deployed identity, authority topology and bounded static/dynamic/adversarial analysis with independent verification and explicit release acceptance.
Blockchain boundary: normal assessment does not require private keys, seed phrases, custody of funds, signing authority, or arbitrary RPC administrative credentials. A material upgrade creates a new target state. Technical blockchain assurance is not a financial-statement audit, legal opinion, regulatory approval or guarantee of economic performance.
What do you enter at checkout?
Stripe checkout collects only the information needed to identify the purchase and begin bounded intake. It is not an evidence-upload form.
TargetPublic URL or PRIVATE
Enter the public project/repository URL. For a non-public system, enter PRIVATE so DDCAL can confirm scope before any non-public material is transferred.
QuestionWhat should be challenged?
State the primary review question, expected behaviour, invariant, authority boundary, failure condition, or concern. Customer text is treated as intake evidence; it cannot expand the purchased technical capability.
EmailWhere the accepted result goes
After payment is independently verified, DDCAL sends the job acknowledgement to the email used at Stripe checkout. The accepted final report is delivered to that same checkout email unless a secure private-evidence delivery path is required.
Checkout boundary: Do not paste file contents, passwords, API keys, tokens, private-repository credentials, personal information, executables, proprietary datasets, or confidential evidence into Stripe fields.
What evidence can an assessment use?
Depending on the service and agreed scope, an assessment can use a URL, actual files, on-chain state, or a combination. The evidence does not have to be a Git repository.
URL / addressPublic target or evidence locator
Examples include a public source repository, stable product or release page, live software URL, API or technical documentation, blockchain network + contract address, browser-extension listing, or another public target that identifies the system being assessed.
FilesSupporting evidence package
Examples include source or configuration files, bounded source archives, requirements and architecture documents, manifests or SBOMs, test output, logs or traces, screenshots, prompt or tool-policy files, deployment configuration, and representative non-sensitive test data.
ClaimDefined decision boundary
Provide the exact version, commit, deployed contract state, or block boundary and the claim you want challenged. DDCAL uses the agreed scope—not the volume of submitted material—to determine what the assessment is authorized to test.
Transfer boundary: Public URLs and public on-chain locators may be supplied during intake. If actual files or non-public evidence are needed, DDCAL confirms scope first and establishes the appropriate evidence-transfer boundary. Do not send sensitive evidence through ordinary email.