I think that public is public, no need to say fully public. If there is an embargo, it isn’t public it is restricted. So public is not compatible with embargo. For me these are not the same kind of state. That’s why I detect some incompatibilities (states that are incompatible). It’s an issue and a solution in the same time. We can have the 3 types of states (for example):

1. Visibility

• not-public
• published

2. Publication process

• (draft)
• scheduled
• published
• withdrawn

3. Disclosure restrictions / or lifecycle (maybe redundant with what we have in BCP-005)

• embargoed
• superseded

That’s why the combinations of any of these states become awkward. But it works with types.

I added draft state for the case when the vulnerability coordinator is currently working on a new advisory. A draft is not necessaru private. I was not fan of this idea of “private draft” because I think that practically some people will use it to write advisory taht are not public (they will stay in draft mode for days). So here we could have a way to say “public draft” or “private draft”. I encourage “public draft” ! And from the beginning. It’s like with open source code. Public even before it is ready to be shown.
So this is a public draft (as encouraged by me):

{
  "publication": {
    "state": "draft",
    "visibility": "public"
  }
}

I would also make published explicitly mean “publicly published”.

and then we can have a model like:

{
  "publication": {
    "state": "published",
    "published_at": "...",
    "visibility": "public"
  },
  "handling": {
    "embargoed": false
  },
  "superseded_by": null
}

but now my issue is:

{
  "publication": {
    "state": "published",
    "published_at": "...",
    "visibility": "public"
  },
  "handling": {
    "embargoed": true
  },
  "superseded_by": null
}

this should be forbidden!
Default value of embargoe should be false. And during the embargoe:

{
  "publication": {
    "state": "scheduled",
    "scheduled_at": "...",
    "visibility": "restricted"
  },
  "handling": {
    "embargo": {
      "until": "2026-11-01T12:00:00Z"
    }
  },
  "superseded_by": null
}

and then we are transparent on when will be the end of the embargo.

state = published implies visibility = public.
When we have the state public the state can be omitted.

As for superseded_by, should we use the same in as in BCP-05. We have relationships and deprecation record type. So I would just set an id here to keep it simple. And don’t add redundancy in the global record.