Theoretical workflow model

Layer model

The system has four layers. Keeping them separate is the main design rule: a bug in the web client must not change the standards profile, and a file upload must not pretend to be a BCF topic.

Standards profile
  -> constrains project extensions and validators

Files
  -> get hash, URL, MIME type, size
  -> become kind:1063 records

Signed events
  -> link to files through e-tags
  -> link to project through a-tags
  -> link to people through p-tags

Interfaces
  -> create, read, validate and render those events

Roles and responsibilities

The process uses two role axes: discipline and authority. Discipline says what a person knows; authority says what they may change.

State machine

ISO 19650 gives the container states. BCF gives issue status. The workflow keeps both: container state tells whether an information container may be relied on; BCF status tells what happened to a coordination problem.

End-to-end happy path

This is the theoretical baseline that each implementation slice should follow. If an interface cannot support one step yet, it must not fake it; it should emit the events it can and leave the rest explicit. The same flow is shown with people and payload examples in Alice, Bob, Max.

BCF issue loop

The issue loop is the first workflow to prove because it covers the core architecture: a normal browser can create a standards-compatible coordination object without owning the whole CDE.

create viewpoint
  -> kind:1063 snapshot file metadata
  -> kind:30901 immutable viewpoint

create topic
  -> kind:30900 current BCF topic

comment
  -> kind:1170 append-only comment

change status / assignee / priority
  -> kind:1171 audit event
  -> new kind:30900 with same d-tag

close
  -> kind:1171 audit event
  -> new kind:30900 status Resolved or Closed

Approval and publication loop

Publication is not a button that changes a label. It is a signed decision that references the information containers being published.

package selected
  -> collect IFC file refs, IDS results, unresolved BCF topics

preflight check
  -> no critical open topics
  -> required IDS checks passed or explicitly waived
  -> all file hashes available

approval
  -> kind:30970 with signer policy
  -> optional OpenTimestamps proof

publication
  -> update container state on relevant file/document records
  -> archive export manifest

Import/export loops

Interoperability is a hard requirement. The event graph must be able to import and export normal openBIM artifacts without losing meaning.

Implementation order

The implementation should follow dependency order, not UI excitement. Each step produces a testable event corpus for the next one.

1. Schema constants. Define event kinds, required tags, value lists and JSON content schemas.
2. Project admin. Create 30902, members, roles and extension lists.
3. File records. Create 1063 and 30904 from referenced files.
4. BCF form. Create minimal 30900 topics with valid tags.
5. Viewpoint support. Add snapshot/file metadata and immutable 30901 records.
6. Thread view. Query topic, comments, audit, viewpoint and snapshot together.
7. Status transitions. Add 1171 audit plus replacement topic state.
8. BCFZIP import/export. Prove round-trip with fixture files.
9. IDS validation. Attach requirements and results to model packages.
10. Approval gate. Add 30970 and publication/export preflight.

Acceptance criteria

This is the practical checklist for deciding whether the theory is clear enough to implement.

Sources

• buildingSMART BCF API 3.0 repository
• buildingSMART BCF XML repository
• Nostr NIP-01 event and tag model
• Nostr NIP-94 file metadata