{"version":"2.1.274","anchor":"bridge-attestation-treats-server-authoredserver-replayed-as","canonical_anchor":"bridge-attestation-treats-server-authoredserver-replayed-as","heading":"New server_authored\/server_replayed event origins normalized in bridge attestation","tier":"internal","area":"Remote Control","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.274\/e\/bridge-attestation-treats-server-authoredserver-replayed-as","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.274","markdown":"### New server_authored\/server_replayed event origins normalized in bridge attestation\n\nRemote-control bridge events can now be tagged as server_authored or server_replayed, and attestation filtering treats both the same as unspecified.\n\n**What**\n\n- The function that maps event-origin strings to display values now recognizes two new values, `server_authored` and `server_replayed`, mapping them to `SERVER_AUTHORED` and `SERVER_REPLAYED` respectively.\n\n- When remote-control bridge events are filtered by device attestation status, events with a `SERVER_AUTHORED` or `SERVER_REPLAYED` status are now normalized to `UNSPECIFIED` before the accept-level\/accept-status checks run.\n\n**Why** This lets the bridge distinguish events that were authored or replayed by the server itself from device-attested events, while ensuring attestation filtering doesn't mistakenly treat them as attested device events.\n\n- Area: Remote Control\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}