The date
| Key |
Expires |
VIEWS Pipeline Core |
2026-11-17 12:35 |
UN FAO |
2026-11-17 16:10 |
crafd-caller-read |
never |
Read from the operator console 2026-08-05, closing þing-02 A3(i). Recorded in views-appwrite registry v1.4.4 (appwrite-seam-v1.4.4), tracked as C-65.
Two things about this that are not obvious:
- The previously circulated figure was
~2026-11-30. It is thirteen days late. That was a relayed approximation, correctly flagged as unverified in seam contract §2, which hardened into a planning number by repetition. Anyone who sized work against it has thirteen fewer days than they think.
- The two platform keys expire 3h35m apart, on the same afternoon. There is no stagger and no fallback — they cannot cover for each other. Whatever rotation sequence happens must complete before that date, not straddle it.
Overlap rotation is mechanically possible — the console holds three independent keys, each with its own scopes and expiry, and creation is self-service (A3(b), answered the same sitting). So a replacement can be issued and live alongside the old one during migration. That is the precondition for doing this without an outage.
What it means here specifically
Both of this repo's Appwrite paths run under VIEWS Pipeline Core — the key that expires first, at 12:35:
views_postprocessing/unfao/ — sole writer of unfao_bucket, the FAO outbound deliveryviews_postprocessing/crafd/ — writer of crafd_bucket
The CRAFD path is worth flagging: it became reachable only when registry v1.4.0 gave the APPWRITE_CRAFD_* coordinates values, and it uses the same datastore key. It is the fourth holder of that key, and it was not on the serves_identities list the key-split work is sized from — raised at views-faoapi#338 as C-57. So this repo is affected twice by the same rotation.
assert_env_declared checks that names were declared, not that the credential behind them is valid, so expiry will surface as an Appwrite error mid-delivery rather than at startup.
What is asked of this repo
Nothing yet. This is a date, not a defect — the rotation is operator work (views-appwrite#12 e-caller) and the split is views-faoapi#338.
Worth knowing given your #187 drift detector fired correctly on 2026-08-03: this is the kind of upstream change that detector exists for, but a key expiry is not visible in the registry, because the registry records secret slots, never values or their lifetimes. No amount of drift detection will surface this one. That asymmetry is the point of filing it.
The date
VIEWS Pipeline CoreUN FAOcrafd-caller-readRead from the operator console 2026-08-05, closing þing-02 A3(i). Recorded in views-appwrite registry v1.4.4 (
appwrite-seam-v1.4.4), tracked as C-65.Two things about this that are not obvious:
~2026-11-30. It is thirteen days late. That was a relayed approximation, correctly flagged as unverified in seam contract §2, which hardened into a planning number by repetition. Anyone who sized work against it has thirteen fewer days than they think.Overlap rotation is mechanically possible — the console holds three independent keys, each with its own scopes and expiry, and creation is self-service (A3(b), answered the same sitting). So a replacement can be issued and live alongside the old one during migration. That is the precondition for doing this without an outage.
What it means here specifically
Both of this repo's Appwrite paths run under
VIEWS Pipeline Core— the key that expires first, at 12:35:views_postprocessing/unfao/— sole writer ofunfao_bucket, the FAO outbound deliveryviews_postprocessing/crafd/— writer ofcrafd_bucketThe CRAFD path is worth flagging: it became reachable only when registry v1.4.0 gave the
APPWRITE_CRAFD_*coordinates values, and it uses the same datastore key. It is the fourth holder of that key, and it was not on theserves_identitieslist the key-split work is sized from — raised at views-faoapi#338 as C-57. So this repo is affected twice by the same rotation.assert_env_declaredchecks that names were declared, not that the credential behind them is valid, so expiry will surface as an Appwrite error mid-delivery rather than at startup.What is asked of this repo
Nothing yet. This is a date, not a defect — the rotation is operator work (views-appwrite#12 e-caller) and the split is views-faoapi#338.
Worth knowing given your #187 drift detector fired correctly on 2026-08-03: this is the kind of upstream change that detector exists for, but a key expiry is not visible in the registry, because the registry records secret slots, never values or their lifetimes. No amount of drift detection will surface this one. That asymmetry is the point of filing it.