Skip to content

feat(runtime): add runtime 1.0 model - #198

Open
niallroche wants to merge 1 commit into
accordproject:mainfrom
niallroche:codex/runtime-1.0-model
Open

feat(runtime): add runtime 1.0 model#198
niallroche wants to merge 1 commit into
accordproject:mainfrom
niallroche:codex/runtime-1.0-model

Conversation

@niallroche

@niallroche niallroche commented Aug 19, 2026

Copy link
Copy Markdown
Contributor

Closes #N/A

Introduces org.accordproject.runtime@1.0.0 after publication of contract@1.0.0. The model keeps generic request and response semantics, gives runtime state stable identity and revision history, and moves reusable obligation vocabulary out of the runtime namespace.

Changes

  • Add versioned 1.0 Request and Response base transactions.
  • Replace the unidentified empty state with a concrete, identified State asset.
  • Bind each state snapshot to its governing contract@1.0.0.Contract.
  • Add revision, effective time, state hash and previous-state hash fields.
  • Remove Obligation from the new runtime namespace; new implementations use org.accordproject.obligation@1.0.0.
  • Preserve the existing unversioned and runtime@0.2.0 models unchanged for compatibility.

Flags

  • This PR must be merged only after contract@1.0.0 is merged and published because the models build resolves imports through models.accordproject.org.
  • stateHash is calculated over the canonical state representation excluding the stateHash property itself.
  • Canonical state serialization and transition validation rules must be documented before publication.
  • Removing the legacy runtime obligation from the 1.0 namespace is intentional. A migration mapping to the dedicated obligation model is still required.
  • The model remains syntactically compatible with Concerto 3 while being validated with Concerto 4.1.5.

Screenshots or Video

Not applicable. This PR contains a Concerto model change only.

Related Issues

Author Checklist

  • Ensure you provide a DCO sign-off for your commits using the --signoff option of git commit.
  • Vital features and changes captured in unit and/or integration tests
  • Commits messages follow AP format
  • Extend the documentation, if necessary
  • Merging to main from niallroche:codex/runtime-1.0-model

Signed-off-by: Niall Roche <niall.roche@gmail.com>
@niallroche
niallroche requested review from dselman and mttrbrts August 19, 2026 13:39
*/
asset State identified by stateId {
o String stateId
--> Contract contract

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I noticed recently that Devanshi was forced to convert all of our sample templates to Contract templates (from Clause templates) because of a similar change in Obligations.

This change mirrors the Obligation design, although collectively it effectively makes Clauses unable to have state and emit Obligations. That could be a sensible design (and today there isn't a technical difference between the two), however we should make this decision consciously.

--> Contract contract
o Long revision default=0 range=[0,]
o DateTime effectiveAt
o ContentHash stateHash

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noting that this makes the Crypto namespace a runtime dependency for all templates.

No immediate concern, but it could force us to rev versions here if we bump minor versions of the crypto model.

* predecessor when one exists. A concrete base state is retained so templates
* which need no additional properties can use it directly.
*
* Obligations are intentionally not defined in this namespace. New

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you consider adding the base Obligation type here (perhaps as abstract), but putting the concrete subclasses in a separate space? I'm trying to judge how much of the obligations namespace is needed for everyday use cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants