diff --git a/FURPS.md b/FURPS.md
new file mode 100644
index 0000000..39b3bbb5
--- /dev/null
+++ b/FURPS.md
@@ -0,0 +1,79 @@
+# Waku FURPS
+
+- 🏗️: New planned property, yet to be delivered.
+- (Vac-DST): Simulations to verify this property
+- (Vac-QA): Additional test coverage by Vac-QA to verify this property
+
+## Core
+
+### Light Push
+
+#### Functionality
+
+1. Enables light nodes to push messages to service nodes for relay to the network.
+2. Requests service nodes to publish messages to WAKU2-RELAY pubsub-topics.
+3. Provides confirmation that a message has been received by at least one node.
+4. 🏗️ Supports comprehensive error codes for various failure scenarios.
+
+#### Usability
+
+1. Implements simple async request/response pattern.
+2. Uses standard Waku Message format.
+3. Only requires an established libp2p connection.
+4. 🏗️ Provides descriptive error messages in responses.
+
+#### Reliability
+
+1. Implements retransmission on failure with exponential backoff.
+2. Implements DoS protection through request rate limitation.
+3. 🏗️ Status codes indicate the best recovery method (retry, discard service node or irrecoverable failure).
+4. 🏗️ 80% message transmission success rate on live Status network (service node from both Status Desktop and fleet Waku instances)
+ 
+#### Performance
+
+1. Only one network round trip is required for operation; including both configuration and message transmission.
+2. Minimizes protocol overhead for efficient resource usage.
+
+#### Supportability
+
+1. nwaku as service node
+2. js-waku as edge node
+
+### Store
+
+#### Functionality
+
+1. Provides historical message retrieval from the Waku network, enabling nodes to query for messages they missed while offline.
+2. Supports multiple query types: time-based, content-topic filtered, and message hash lookups.
+3. Enables message presence verification without retrieving full message content.
+4. Supports pagination for efficient retrieval of large message sets, and resuming retrieval after disconnection.
+5. Supports comprehensive error codes for various failure scenarios.
+6. 🏗️ Industry practices are applied to PostgreSQL setup to reach appropriate performance
+
+### Usability
+
+1. Implements simple async request/response pattern.
+2. Uses standard Waku Message format.
+3. Only requires an established libp2p connection.
+4. Provides descriptive error messages in responses.
+5. Supports query filtering to retrieve only relevant messages by content topic.
+
+#### Reliability
+
+1. Implements DoS protection through request rate limitation.
+2. (limitation) No guarantees in terms of message presence or retention duration
+
+#### Performance
+
+1. Only one network round trip is required for operation; including both configuration and message retrieval.
+2. Implements pagination to manage resource usage on both client and server.
+3. Allows presence queries to verify message existence without transferring full content.
+4. Targets query response times under 2 seconds for typical requests.
+5. 🏗️ Hash query of less than 10 hashes are served under 400ms; for a database less than 250 GB size and average message size under 500KiB **(Vac-DST)**.
+6. 🏗️ Time range queries of less than 24 hours, with less than 10 content topics, are served under 400 ms; for a database less than 250 GB size and average message size under 500KiB **(Vac-DST)**.
+
+#### Supportability
+
+1. nwaku support as service node.
+2. Uses PostgreSQL as database engine.
+3. Browser support (js-waku) as client.
\ No newline at end of file
diff --git a/ROADMAP.md b/ROADMAP.md
index f267c29..3270e07 100644
--- a/ROADMAP.md
+++ b/ROADMAP.md
@@ -1 +1,67 @@
-Roadmap and milestones can be found on the [Logos roadmap](https://roadmap.logos.co/waku/).
\ No newline at end of file
+Roadmap and milestones can be found on the [Logos roadmap](https://roadmap.logos.co/waku/).
+
+## Draft Milestones
+
+Testing out new format, final roadmap to be pushed in Logos roadmap.
+
+### Peer-To-Peer Reliability
+
+Last remains of *Direct Message Reliability* milestone.
+
+Once delivered, the the reliability of the Waku protocols will be maximised when used with decentralised light push and filter service nodes;
+in mostly offline or frequently disconnected environments (mobile, laptop).
+
+This may include some bandwidth overhead that can later be optimized when rolling out enhanced end-to-end reliability strategies.
+This includes a high reliance on centralized store nodes.
+
+User experience is catered for, in terms of delay of message retrieval and retention,
+which is why store performance is also review and maximized for the current circumstances.
+Limited effort will be spent on store performance as its relevance is expected to reduce mid-long term.
+
+**Deliverables**:
+
+#### Define and Implement Light Push Error codes in nwaku.
+
+**Owner**: nwaku
+
+**Feature**: Light Push
+
+**FURPS**:
+- F4: Supports comprehensive error codes for various failure scenarios.
+- U4: Provides descriptive error messages in responses.
+- R3: Status codes indicate the best recovery method (retry, discard service node or irrecoverable failure).
+- R4: 80% message transmission success rate on live Status network (service node from both Status Desktop and fleet Waku instances)
+
+For S1: nwaku as service node
+Includes spec delivery
+
+#### Implement Light Push Error codes in The Browser
+
+**Owner**: js-waku
+
+**Feature**: Light Push
+
+**FURPS**:
+- F4: Supports comprehensive error codes for various failure scenarios.
+- U4: Provides descriptive error messages in responses.
+- R3: Status codes indicate the best recovery method (retry, discard service node or irrecoverable failure).
+
+For S2: js-waku as edge node
+Spec delivery not included.
+
+#### PostgreSQL Optimisation Phase 1
+
+**Owner**: nwaku
+
+**Feature**: Store
+
+**FURPS**:
+- F6: Industry practices are applied to PostgreSQL setup to reach appropriate performance
+- P5:️ Hash query of less than 10 hashes are served under 400ms; for a database less than 250 GB size and average message size under 500KiB **(Vac-DST)**.
+- P6:️ Time range queries of less than 24 hours, with less than 10 content topics, are served under 400 ms; for a database less than 250 GB size and average message size under 500KiB **(Vac-DST)**.
+
+For S1: nwaku support as service node.
+
+#### P2P Reliability Implementation in the Browser
+
+TBD
\ No newline at end of file