# Build and contribute

The initial repository is a private development workspace with documentation, a static site, and repository checks. Open-source publication and executable releases require a separate review. No license should be assumed before an explicit license file is approved.

## Engineering approach

One deterministic core; thin delivery wrappers; source-specific adapters; and original evidence preserved. Use reviewed cryptographic libraries. Do not create a separate policy interpretation in every SDK language.

Read `AGENTS.md` before editing. Work in small branches with clear acceptance criteria. Record exact dependency versions and upstream specification revisions. Include a failure fixture with each successful example.

## Review criteria

Changes must preserve the brand, precise proof claims, fail-closed behavior, bounded parsing/fetching, and separation between evaluation and authorization. Security-sensitive changes need independent review, not simply another model agreeing with the author.

## Repository structure

`docs/` is the documentation source. `brand/` defines visual identity and tokens. `specs/` contains provisional schemas. `site/` is the standalone static website. `scripts/` contains local documentation checks. `ops/` holds private setup notes and a snapshot of publishing state.

Future runtime packages should be added only when implemented. Empty folders and package commands must not be presented as completed software.

## Contribution workflow

Create an issue describing the problem, evidence requirements, non-goals, and success/failure cases. Implement behind the relevant status gate. Run repository checks, describe the actual tests performed, and request review. Never commit customer secrets or move live funds as a test.

<!-- p21-source-payment-v08 -->

## Additional source and payment conformance cases

Test duplicate names and duplicate field/pattern signatures, unsupported fields or regex semantics, incorrect inscription content, mismatched source hashes, incomplete registry history, wrong network and source reorganization. Test nonce-only/known-source claims, post-source commitments, changed ordering or weights, request-ID/context grinding, retries and withheld outcomes.

For native NAT, test the wrong deployment/ticker/network/recipient, a UNAT-only transfer, a created but unexecuted transfer inscription, partial/late/overpayment, stale or lagging observations, conflicting indexes, insufficient confirmations, duplicate event crediting, concurrent reservations, caller mismatch, refund replay and reorganization after credit use. Exercise the same request independently through the USDC rail. A synthetic policy test is not a real-funds settlement test.


[1] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/digital-elements/.element-registry

[2] https://github.com/Trac-Systems/ord-tap/blob/b8f6ea35cf6b9d405d4db7c58555e3c8ab33e8cd/src/index/updater/inscription_updater/tap/ops/dmt_element.rs

[3] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/nat-use-cases/usdnat-method-1-live

[4] https://digital-matter-theory.gitbook.io/digital-matter-theory/introduction/non-arbitrary-tokens-nats/nat-token-transfer

[5] https://docs.x402.org/core-concepts/network-and-token-support

[6] https://github.com/Trac-Systems/ord-tap/blob/b8f6ea35cf6b9d405d4db7c58555e3c8ab33e8cd/README.md

[7] https://arxiv.org/abs/1605.04559