Conceptual reference
Development status: Overview — This section contains conceptual reference: documentation-level definitions and conventions, not technical reference for a released interface. An experimental developer-facing node interface exists for internal testing only; its methods, formats and versions are not published. Further technical reference is not yet available, and nothing is publicly available for live use.
Before you read: About the Cubane developer documentation.
Where are the reference-style definitions for interfaces, lifecycle terms, failures, examples and terminology? They are in this section. Its pages answer reference-style questions at the level of concepts, because there is not yet a released interface to document in technical detail.
What is in this section
- Interfaces and their status — which interface families exist experimentally, and which are planned or being explored.
- Lifecycle stages used in this documentation — the stage terms used across all pages, such as submitted, recorded and final.
- What can go wrong: failure and error concepts — the failure categories applications should design for.
- How illustrative examples work in this documentation — the rules every example follows.
- Glossary — the single place where terms are defined.
- Topic index — an alphabetical route to every page.
Why there is no versioned technical reference
No interface has been released, so there is no stable surface to document. An experimental developer-facing node interface exists for internal testing; the broader developer API design is being explored. Method names, parameters, formats, error codes and endpoints are not published.
Further technical reference is not yet available.
When versioned technical reference would be added
Versioned technical reference would be added only when all of the following are true:
- a release exists, and its version identity is shown on every reference page;
- there is evidence that the documented interface is actually available;
- the reference has been approved for publication and checked against the released software.
Until then, the pages in this section meet reference-style needs at the level of concepts: they define terms, categories and conventions that would stay meaningful whatever form a released interface takes.
How to use conceptual reference
- Documentation terms are not identifiers. Terms defined here are documentation terms; they are not protocol status values, field names or identifiers.
- One concept, one defining page. Each concept is defined in one place, and other pages link to it rather than redefine it.
- Status travels with the term. Each term carries the status of the concept it names, stated in text.
- Labels and dates have their own page. Status labels and review dates are explained on Documentation conventions: status labels, dates and reviews.
Assumptions, trust and limitations
Conceptual definitions may change as designs settle; any change would be recorded in the Documentation change log. Nothing in this section is an interface specification, a compatibility promise or a statement that any interface is available.
Not yet available, and how this page will grow
When releases exist, versioned reference — such as interface and error reference — would be added alongside these pages, each tied to a version. Further technical reference is not yet available.
Related pages
- Interfaces and their status — interface families and their status.
- Lifecycle stages used in this documentation — stage terms.
- What can go wrong: failure and error concepts — failure categories.
- How illustrative examples work in this documentation — example conventions.
- Glossary — term definitions.
- Topic index — alphabetical route to every page.
- Documentation conventions: status labels, dates and reviews — status labels and review dates.
Glossary
References
No approved public references yet.
