@@ -138,7 +138,7 @@ pub use p2panda_encryption::key_bundle::LongTermKeyBundle;
 use p2panda_encryption::crypto::x25519::SecretKey;
 use p2panda_encryption::crypto::xchacha20::XAeadNonce;
 use p2panda_encryption::data_scheme::{
-    EncryptionGroup, GroupState, GroupSecretId, decrypt_data, encrypt_data,
+    EncryptionGroup, GroupState, GroupSecretId, SecretBundle, decrypt_data, encrypt_data,
 };
 use p2panda_encryption::key_bundle::Lifetime;
 use p2panda_encryption::key_manager::{KeyManager, KeyManagerState};
@@ -837,12 +837,18 @@ impl Vault {
     /// returned tag is what the subject's own private book should file them
     /// under — the grant itself names nobody.
     ///
-    /// ⚠️ **A GRANT REACHES BACK OVER EVERYTHING, AND CANNOT BE ASKED NOT TO.**
+    /// ⚠️ **THIS GRANT REACHES BACK OVER EVERYTHING.**
     /// `EncryptionGroup::add` hands the joiner `&y.secrets` — the whole secret
     /// bundle — so a reader granted today opens every day the subject still
     /// holds a secret for, including days sealed long before they were granted.
-    /// There is no `history` flag and no way to pass a narrower bundle: the
-    /// library does not expose one.
+    ///
+    /// **"AND CANNOT BE ASKED NOT TO" USED TO FOLLOW, AND IT WAS WRONG.** This
+    /// said "there is no `history` flag and no way to pass a narrower bundle:
+    /// the library does not expose one." There is no flag, true. But
+    /// `GroupState::secrets` is a public field and `update_secrets` a public
+    /// setter, so the bundle handed over is whatever is in that field when
+    /// `add` runs — see [`Vault::grant_since`], which narrows it and is tested.
+    /// The claim stood unchallenged until somebody ran the spike D29 asked for.
     ///
     /// **THAT IS LESS THAN BOTH VAULTS THIS REPLACES.** `diaswarm-core` wraps
     /// per segment, so the subject chooses what a reader can open;
@@ -869,7 +875,7 @@ impl Vault {
         bundle: LongTermKeyBundle,
         purpose: &str,
     ) -> Result<(Message, GrantTag), Error> {
-        self.grant_inner(bundle, purpose, false)
+        self.grant_inner(bundle, purpose, false, None)
     }
 
     /// Grant without anybody watching — for a handover, and nothing else.
@@ -890,14 +896,65 @@ impl Vault {
         bundle: LongTermKeyBundle,
         purpose: &str,
     ) -> Result<(Message, GrantTag), Error> {
-        self.grant_inner(bundle, purpose, true)
+        self.grant_inner(bundle, purpose, true, None)
+    }
+
+    /// Grant a reader only the secrets created at or after `since`.
+    ///
+    /// **THIS IS THE THING [`Vault::grant`]'s warning says cannot be done, and
+    /// it turns out it can.** That comment reads "there is no `history` flag and
+    /// no way to pass a narrower bundle: the library does not expose one." The
+    /// first half is true and the second is not. `EncryptionGroup::add` hands
+    /// the joiner `&y.secrets`, but `y.secrets` is a public field and
+    /// `EncryptionGroup::update_secrets` is a public setter, so the bundle the
+    /// joiner receives is whatever is in that field at the moment `add` runs.
+    /// Narrow it, add, put it back.
+    ///
+    /// No fork, no private API, no waiting on upstream — which is what D29
+    /// predicted, though not by the route it proposed: dropping to `Dcgka::add`
+    /// does not work, because reassembling what `EncryptionGroup::add` does
+    /// afterwards needs `process_local`, and that *is* private.
+    ///
+    /// ⚠️ **`since` IS UNIX SECONDS, AND IT FILTERS BY WHEN THE SECRET WAS
+    /// MADE — NOT BY WHAT IT COVERS.** `GroupSecret`'s timestamp is stamped
+    /// from `SystemTime::now()` at creation. So this scopes to rotation
+    /// boundaries, and "the last 90 days" means "everything sealed since the
+    /// secret that was current 90 days ago" — which is only the same sentence
+    /// if the subject rotates on a schedule. Rotating daily makes them agree to
+    /// the day; not rotating at all makes this a no-op, because one secret
+    /// covers everything.
+    ///
+    /// ⚠️ **AND IT IS NOT A REVOCATION.** A reader who already holds an older
+    /// secret keeps it. This narrows what a *new* grant hands over; it takes
+    /// nothing back. [`Vault::revoke`] is what bites, and it bites forward.
+    pub fn grant_since(
+        &mut self,
+        bundle: LongTermKeyBundle,
+        purpose: &str,
+        since: u64,
+    ) -> Result<(Message, GrantTag), Error> {
+        self.grant_inner(bundle, purpose, false, Some(since))
+    }
+
+    /// Rotate the group secret, so what follows is sealed under a new one.
+    ///
+    /// Needed for [`Vault::grant_since`] to mean anything: the scope it can
+    /// express is only as fine as the rotation boundaries that exist.
+    pub fn rotate(&mut self) -> Result<Message, Error> {
+        let state = self.state.take().ok_or(Error::NoSecret)?;
+        let (state, msg) =
+            Group::update(state, &self.rng).map_err(|e| Error::Group(e.to_string()))?;
+        self.state = Some(state);
+        self.save()?;
+        msg.stamp(self.me)
     }
 
     fn grant_inner(
         &mut self,
         bundle: LongTermKeyBundle,
         purpose: &str,
         unattended: bool,
+        since: Option<u64>,
     ) -> Result<(Message, GrantTag), Error> {
         let mut state = self.state.take().ok_or(Error::NoSecret)?;
         let tag = Self::tag_for(&state.dcgka.my_keys, &bundle, purpose)?;
@@ -914,8 +971,26 @@ impl Vault {
         }
         state.dcgka.pki = KeyRegistry::add_longterm_bundle(state.dcgka.pki, tag, bundle)
             .map_err(|e| Error::Crypto(e.to_string()))?;
-        let (state, msg) =
+        // **THE WHOLE OF A SCOPED GRANT IS THESE THREE LINES.** `Group::add`
+        // hands the joiner whatever is in `y.secrets`, so the narrowing happens
+        // here and is undone immediately afterwards. Keeping the full bundle in
+        // a local rather than re-deriving it matters: `add` must not be able to
+        // leave this vault holding less than it started with, or the subject
+        // would lose the ability to read its own history by granting somebody.
+        // `SecretBundleState` is only `Clone` under the crate's `test_utils`
+        // feature, so the snapshot is of the secrets themselves — which are
+        // `Clone` — and the bundle is rebuilt from them.
+        let full: Vec<_> = state.secrets.secrets().cloned().collect();
+        if let Some(since) = since {
+            let kept: Vec<_> =
+                full.iter().filter(|s| s.timestamp() >= since).cloned().collect();
+            state.secrets = SecretBundle::from_secrets(kept);
+        }
+        let (mut state, msg) =
             Group::add(state, tag, &self.rng).map_err(|e| Error::Group(e.to_string()))?;
+        if since.is_some() {
+            state.secrets = SecretBundle::from_secrets(full);
+        }
         self.state = Some(state);
         self.save()?;
         Ok((msg.stamp(self.me)?, tag))
 
@@ -0,0 +1,193 @@
+//! Can a grant be made to reach back only so far?
+//!
+//! **THIS IS THE SPIKE [D29](../../../docs/decisions.md) ASKED FOR, AND IT
+//! EXISTS BECAUSE THAT DECISION ENDS BY SAYING IT HAD NOT BEEN RUN.** The words
+//! were: *"This is read from the source. Nothing has been built, compiled or
+//! measured, and on the evidence of this repository's last three days that
+//! distinction is the whole difference between a finding and a result."*
+//!
+//! The finding was that a time-scoped grant is reachable on pinned
+//! p2panda-encryption 0.7.1. That much holds. The route does not: D29 proposed
+//! dropping to `Dcgka::add`, which takes the bundle as a parameter — but
+//! rebuilding what `EncryptionGroup::add` does around it needs `process_local`,
+//! and that is private. The way through is one layer higher and simpler.
+//! `GroupState::secrets` is a public field and `update_secrets` is a public
+//! setter, so the bundle a joiner receives is whatever is in that field when
+//! `add` runs.
+//!
+//! What this file asserts is the only thing that matters about that: a reader
+//! granted from a narrowed bundle can open what came after the cut and cannot
+//! open what came before it.
+
+use diaswarm_core::{EPOCH_MS, Record};
+use diaswarm_keys::{Vault, wire};
+use p2panda_core::SigningKey;
+use p2panda_encryption::Rng;
+use p2panda_store::SqliteStoreBuilder;
+
+const OFFSET: i64 = 12 * 3_600_000;
+
+fn rand32() -> [u8; 32] {
+    use std::time::{SystemTime, UNIX_EPOCH};
+    let n = SystemTime::now().duration_since(UNIX_EPOCH).unwrap().as_nanos();
+    let mut out = [0u8; 32];
+    out[..16].copy_from_slice(&n.to_le_bytes());
+    out[16..].copy_from_slice(&(n ^ 0x9E37_79B9_7F4A_7C15).to_le_bytes());
+    out
+}
+
+fn tmp(tag: &str) -> std::path::PathBuf {
+    let p = std::env::temp_dir().join(format!(
+        "diaswarm-scoped-{tag}-{}",
+        std::time::SystemTime::now().duration_since(std::time::UNIX_EPOCH).unwrap().as_nanos()
+    ));
+    std::fs::create_dir_all(&p).unwrap();
+    p
+}
+
+fn day(epoch: i64) -> Vec<Record> {
+    (0..4i64)
+        .map(|i| {
+            Record::new(epoch * EPOCH_MS + i * 300_000, "cgm")
+                .set("mgdl", Some((100.0 + i as f64).into()))
+        })
+        .collect()
+}
+
+fn now_secs() -> u64 {
+    std::time::SystemTime::now()
+        .duration_since(std::time::UNIX_EPOCH)
+        .unwrap()
+        .as_secs()
+}
+
+/// A SCOPED GRANT OPENS WHAT CAME AFTER THE CUT, AND NOTHING BEFORE IT.
+///
+/// The subject seals a day, rotates the secret, seals another, then grants a
+/// reader with `since` set between the two rotations. The reader gets one day,
+/// not two — which is the sentence a clinician-facing "share the last 90 days"
+/// has to be able to mean.
+#[tokio::test(flavor = "multi_thread")]
+async fn a_grant_can_be_scoped_to_secrets_made_after_a_cutoff() {
+    let rng = Rng::default();
+    let subject_key = SigningKey::from_bytes(&rand32());
+    let reader_key = SigningKey::from_bytes(&rand32());
+    let root = tmp("scoped");
+
+    let mut subject = Vault::open(&root, OFFSET, &subject_key).expect("subject");
+    let (subject_mgr, subject_bundle) = Vault::key_bundle(&rng).expect("bundle");
+    let (reader_mgr, reader_bundle) = Vault::key_bundle(&rng).expect("bundle");
+    subject.create(subject_mgr).expect("create");
+
+    // ---- the old day, under the first secret ----
+    subject.seal(20_000, &day(20_000)).expect("seal old");
+
+    // **THE CUT HAS TO BE A WHOLE SECOND LATER.** `GroupSecret`'s timestamp is
+    // UNIX *seconds* taken from `SystemTime::now()`, so two secrets minted in
+    // the same second are indistinguishable to any filter over them. That is a
+    // real limit on how finely this can scope, not a quirk of the test.
+    std::thread::sleep(std::time::Duration::from_millis(1_100));
+    let cutoff = now_secs();
+
+    subject.rotate().expect("rotate");
+    assert!(subject.secrets() >= 2, "rotation did not add a secret");
+
+    // ---- the new day, under the second ----
+    subject.seal(20_001, &day(20_001)).expect("seal new");
+
+    // ---- the grant, scoped ----
+    let (welcome, _tag) =
+        subject.grant_since(reader_bundle, "follow", cutoff).expect("scoped grant");
+
+    // Through the wire, because that is the only way to get an `Authentic` and
+    // the only path a real reader has.
+    let store = SqliteStoreBuilder::memory().build().await.expect("store");
+    wire::publish_control(&store, &subject_key, &welcome).await.expect("publish");
+    let mut arrived = wire::control_from(&store, &subject_key.verifying_key(), None)
+        .await
+        .expect("read control");
+    let welcome = arrived.pop().expect("welcome");
+
+    // **THE SAME ROOT, SO THE READER CAN SEE THE SEGMENTS.** Counting secrets
+    // is a proxy; what is actually claimed is what can be opened, and that
+    // needs the ciphertext in front of it.
+    let mut reader = Vault::open(&root, OFFSET, &reader_key).expect("reader");
+    let registry =
+        Vault::registry(&[(subject.subject(), subject_bundle.clone())]).expect("registry");
+    reader.join(reader_mgr, registry, &subject_bundle, "follow", &welcome).expect("join");
+
+    // The reader holds exactly one secret: the one minted after the cut.
+    assert_eq!(
+        reader.secrets(),
+        1,
+        "a scoped grant handed over {} secrets, not 1",
+        reader.secrets()
+    );
+
+    // ---- and this is the claim itself ----
+    let (got, skipped) = reader.read_reporting(i64::MIN).expect("reader reads");
+    assert!(got.contains_key(&20_001), "the scoped reader could not open the day it was granted");
+    assert!(
+        !got.contains_key(&20_000),
+        "the scoped reader opened the day BEFORE its cutoff — the narrowing did nothing"
+    );
+    assert_eq!(
+        skipped.not_ours, 1,
+        "expected exactly one day withheld, got {:?}",
+        skipped
+    );
+
+    // ---- and the subject did not lose anything by granting ----
+    assert!(
+        subject.secrets() >= 2,
+        "granting narrowly left the subject holding {} secrets",
+        subject.secrets()
+    );
+    let mine = subject.read_from(i64::MIN).expect("subject reads own history");
+    assert_eq!(mine.len(), 2, "the subject can no longer read its own two days");
+}
+
+/// AND AN UNSCOPED GRANT STILL REACHES BACK OVER EVERYTHING.
+///
+/// The control. If this passes and the one above does not, the narrowing did
+/// nothing; if both pass, `since` is what made the difference.
+#[tokio::test(flavor = "multi_thread")]
+async fn an_unscoped_grant_still_hands_over_the_whole_history() {
+    let rng = Rng::default();
+    let subject_key = SigningKey::from_bytes(&rand32());
+    let reader_key = SigningKey::from_bytes(&rand32());
+    let root = tmp("unscoped");
+
+    let mut subject = Vault::open(&root, OFFSET, &subject_key).expect("subject");
+    let (subject_mgr, subject_bundle) = Vault::key_bundle(&rng).expect("bundle");
+    let (reader_mgr, reader_bundle) = Vault::key_bundle(&rng).expect("bundle");
+    subject.create(subject_mgr).expect("create");
+
+    subject.seal(20_000, &day(20_000)).expect("seal old");
+    std::thread::sleep(std::time::Duration::from_millis(1_100));
+    subject.rotate().expect("rotate");
+    subject.seal(20_001, &day(20_001)).expect("seal new");
+
+    let (welcome, _tag) = subject.grant(reader_bundle, "follow").expect("grant");
+
+    let store = SqliteStoreBuilder::memory().build().await.expect("store");
+    wire::publish_control(&store, &subject_key, &welcome).await.expect("publish");
+    let mut arrived = wire::control_from(&store, &subject_key.verifying_key(), None)
+        .await
+        .expect("read control");
+    let welcome = arrived.pop().expect("welcome");
+
+    let mut reader = Vault::open(&root, OFFSET, &reader_key).expect("reader");
+    let registry =
+        Vault::registry(&[(subject.subject(), subject_bundle.clone())]).expect("registry");
+    reader.join(reader_mgr, registry, &subject_bundle, "follow", &welcome).expect("join");
+
+    assert!(
+        reader.secrets() >= 2,
+        "an unscoped grant handed over only {} secret(s) — the control is broken",
+        reader.secrets()
+    );
+    let (got, skipped) = reader.read_reporting(i64::MIN).expect("reader reads");
+    assert_eq!(got.len(), 2, "an unscoped reader should see both days, saw {}", got.len());
+    assert_eq!(skipped.not_ours, 0, "an unscoped reader was refused a day: {:?}", skipped);
+}
@@ -1219,11 +1219,38 @@ rotation boundaries rather than to days. Day-granular windows therefore mean
 rotating daily — and D26 measured that: a year of daily rotation is a
 366-secret bundle and a **0.76 ms** welcome.
 
-⚠️ **This is read from the source. Nothing has been built, compiled or
-measured**, and on the evidence of this repository's last three days that
-distinction is the whole difference between a finding and a result. The spike
-that would settle it is small: filter a bundle, `Dcgka::add` with it, assert the
-joiner opens epoch N and fails on epoch N−1.
+#### ✅ The spike ran, 2026-09-16 — and the route above is wrong
+
+The conclusion holds: **a time-scoped grant is reachable on pinned 0.7.1, with no
+fork.** `Vault::grant_since` ships it, and
+`crates/diaswarm-keys/tests/scoped_grant.rs` asserts the thing that matters —
+a reader granted with a cutoff opens the day after it, is refused the day
+before it (`Skipped::not_ours == 1`), and the subject still reads its own
+history. An unscoped grant is the control and still hands over everything.
+
+**But not by dropping to `Dcgka::add`.** That takes the bundle as a parameter,
+as read — however rebuilding what `EncryptionGroup::add` does around it needs
+`process_local`, which is **private**. The table above lists the four things
+that are public and misses the one that is not.
+
+**The way through is one layer higher and simpler.** `GroupState::secrets` is a
+public field and `EncryptionGroup::update_secrets` is a public setter, so the
+bundle a joiner receives is whatever sits in that field when `add` runs. Narrow
+it, add, put it back — three lines, no private API, no fork.
+
+⚠️ **Two limits the source reading did not surface**, both now in
+`grant_since`'s doc:
+
+* `GroupSecret`'s timestamp is **UNIX seconds stamped at creation**, not a
+  property of the data. So this scopes by *when the secret was minted*, and
+  "the last 90 days" only means that if the subject rotates on a schedule.
+  Without rotation it is a no-op, because one secret covers everything.
+  `Vault::rotate` exists for that and is what the spike uses.
+* Two secrets minted in the same second are indistinguishable to any filter over
+  them. Second granularity is the floor.
+
+**It is not a revocation.** A reader already holding an older secret keeps it.
+This narrows what a *new* grant hands over. [`Vault::revoke`] is what bites.
 
 #### Sequencing, and why this order