AGNC | Cortensor Node Operator

🛠️ DevLog – Rough Direction for an Inference Quality Prover / Oracle We’ve started thinking more concretely about the Inference Quality Prover / Oracle, which is one of the remaining pieces for improving ephemeral-node quality control. 🔹 Current direction The rough idea is to fork the current Node Pool Oracle model, since that already regulates node-pool population and helps decide which nodes are released into pool and reserved sessions for ephemeral use. 🔹 Current baseline Right now, Node Pool Oracle runs every 5 minutes and decides what should be included in the pool so sessions can use those nodes as ephemeral workers. 🔹 New oracle idea - The Inference Quality Oracle would be a similar periodic oracle, but focused on actual inference behavior instead of just pool availability. - Current rough thought is that it would run every 15 minutes and use 3-miner sessions to check real inference quality on actual user-style tasks. 🔹 Current metrics At the moment, the main three signals we already have for user-task completeness are: - Ack - Precommit - Commit 🔹 Open design area - It is still not fully clear what the final point system should look like, but the likely direction is to use a similar count/point-based approach. - We still need to think more about how these metrics should be scored, stored, ranked, and used inside the data module. 🔹 What’s next The next step is to go deeper on the oracle-side design/code first. After that, we’ll think more carefully about how the resulting data should be used in routing, ranking, and broader quality control. #Cortensor #DevLog #InferenceQuality #Oracle #EphemeralNodes #NodePool

🗓️ Weekly Focus – Phase #3 Support, v3 /delegate & /validate Iteration & MVP Data Management Testing 🔹 Phase #3 – Support, Monitoring & Stats - Continue active monitoring across routing, miners, validators, dashboards, and L3 stats. - Track stability as more features move into deeper testing. 🔹 v3 /delegate + /validate – Iteration - With last week’s prep done, we’ll now iterate more deeply on /delegate and /validate to make them more solid. - Focus on real delegation/validation paths, routing behavior, and closing logic gaps from early tests. 🔹 Privacy Feature 1.0 – Regression Testing - Run deeper regression on session-scope and task-scope encryption. - Cover both dedicated-node and ephemeral-node paths again to confirm stability. 🔹 Offchain Storage v3 – Regression Testing - Run deeper regression on dedicated-node and ephemeral-node storage flows, including deferred writes. - Re-check storage behavior and operator-configured offchain paths. 🔹 MVP Data Management – Full E2E Tests - After testing each feature separately, run combined privacy + offchain end-to-end tests again. - Goal: confirm the full MVP stack works consistently across dedicated, ephemeral, router, miner, and dashboard flows. 🔹 Dashboard – UI/UX Refinement - Keep refining dashboard UX around privacy scope and offchain storage so these flows are easier to use in practice. 🔹 Inference Quality Control – Rough Design - Spend a bit of time on rough design for ephemeral-node inference quality control using real task probes and sliding-window stats. - Goal: improve routing and reliability based on recent functional behavior, not just static availability. This week is about pushing the MVP data-management stack through a more serious validation cycle, tightening v3 agent surfaces, and doing early design work on inference quality control. #Cortensor #Testnet #Phase3 #AIInfra #DePIN #Corgent #Bardiel #Delegate #Validate #PrivateAI #L3

🛠️ DevLog – Starting Consensus-Mode Tests on v3 /delegate & /validate We’ve now started running tests on both v3 /delegate and v3 /validate with consensus mode turned on. 🔹 What this means Instead of returning too early, the router now waits until the task fully ends, then pulls the available results and uses score/aggregation logic to produce a single consensus-style signal at the router level. 🔹 Current flow - nodes process the task first - router waits for TaskEnded - router pulls the returned results - router applies consensus scoring / aggregation - router returns a single consensus-style metric along with the broader result path 🔹 Why this matters This is the beginning of the more reliability-oriented path we wanted for v3 /delegate and /validate, especially when multiple nodes are involved and we want more than just the first result back. 🔹 Current status This is just the start of testing on this new path. From here, we’ll run more matrix tests and stress tests as well, including heavier inputs and broader request patterns. #Cortensor #DevLog #Delegate #Validate #Consensus #AgenticAI

🛠️ DevLog – Router Node - Added the Consensus Helper for /validate As the second part of the current /validate consensus-gap work, we’ve now finished the router-side consensus helper and pushed it into the same PR as well. 🔹 What this fills - The first part made the router wait for the task to fully end and collect the available outputs. - This second part is the piece that actually turns those outputs into one final response instead of just returning raw results. 🔹 What it does - At a high level, the new helper lets the router look at the returned outputs, resolve them as needed, and combine them into a single consensus-style answer. - That can later support things like majority-style verdicts, averaged scores, or other aggregation policies. 🔹 Why this matters This was the other main gap on the /validate side. Waiting for the fuller result set is only half of the solution - the router also needs a way to turn multiple outputs into something more meaningful at the product level. 🔹 Current status - Implementation/fill-gap side is now done - No tests yet - This is mainly about getting the missing consensus piece in place first, then we can iterate and validate the behavior afterward #Cortensor #DevLog #Validate #Consensus #RouterNode #AgenticAI

🛠️ DevLog – Closing the Main Consensus Gap on v3 /validate Following the last two updates, we’ve now technically closed the main gap on v3 /validate for router-level consensus. 🔹 What gap is now filled Before, the router could return too early and did not really have a clean consensus path at the product level. Now that gap is filled in two parts: - router can wait for the task to fully end instead of stopping at the first result - router can then look across the returned outputs and produce a consensus-style response at the router level 🔹 Why this matters - That means /validate is no longer limited to behaving like a fast single-result path only. - It now has the core shape needed to support a more reliability-oriented validation flow where the router can use the broader result set before returning the final answer. 🔹 What this enables With this in place, v3 /validate should now be able to form consensus from 3 and 5 node sessions as an additional signal, while still returning the full task-result set from all miners as part of the broader response path. 🔹 What’s next - Next, we’ll set up a proper test plan for both matrix tests and stress tests around these changes. - The goal there is to confirm the new consensus path behaves correctly across the different replica/session setups and holds up under repeated use. #Cortensor #DevLog #Validate #Consensus #AgenticAI #RouterNode

🗓️ Weekly Focus – Phase #3 Support, v3 /delegate & /validate Iteration & MVP Data Management Testing 🔹 Phase #3 – Support, Monitoring & Stats - Continue active monitoring across routing, miners, validators, dashboards, and L3 stats. - Track stability as more features move into deeper testing. 🔹 v3 /delegate + /validate – Iteration - With last week’s prep done, we’ll now iterate more deeply on /delegate and /validate to make them more solid. - Focus on real delegation/validation paths, routing behavior, and closing logic gaps from early tests. 🔹 Privacy Feature 1.0 – Regression Testing - Run deeper regression on session-scope and task-scope encryption. - Cover both dedicated-node and ephemeral-node paths again to confirm stability. 🔹 Offchain Storage v3 – Regression Testing - Run deeper regression on dedicated-node and ephemeral-node storage flows, including deferred writes. - Re-check storage behavior and operator-configured offchain paths. 🔹 MVP Data Management – Full E2E Tests - After testing each feature separately, run combined privacy + offchain end-to-end tests again. - Goal: confirm the full MVP stack works consistently across dedicated, ephemeral, router, miner, and dashboard flows. 🔹 Dashboard – UI/UX Refinement - Keep refining dashboard UX around privacy scope and offchain storage so these flows are easier to use in practice. 🔹 Inference Quality Control – Rough Design - Spend a bit of time on rough design for ephemeral-node inference quality control using real task probes and sliding-window stats. - Goal: improve routing and reliability based on recent functional behavior, not just static availability. This week is about pushing the MVP data-management stack through a more serious validation cycle, tightening v3 agent surfaces, and doing early design work on inference quality control. #Cortensor #Testnet #Phase3 #AIInfra #DePIN #Corgent #Bardiel #Delegate #Validate #PrivateAI #L3

🛠️ DevLog – Router Node - Added the Consensus Helper for /validate As the second part of the current /validate consensus-gap work, we’ve now finished the router-side consensus helper and pushed it into the same PR as well. 🔹 What this fills - The first part made the router wait for the task to fully end and collect the available outputs. - This second part is the piece that actually turns those outputs into one final response instead of just returning raw results. 🔹 What it does - At a high level, the new helper lets the router look at the returned outputs, resolve them as needed, and combine them into a single consensus-style answer. - That can later support things like majority-style verdicts, averaged scores, or other aggregation policies. 🔹 Why this matters This was the other main gap on the /validate side. Waiting for the fuller result set is only half of the solution - the router also needs a way to turn multiple outputs into something more meaningful at the product level. 🔹 Current status - Implementation/fill-gap side is now done - No tests yet - This is mainly about getting the missing consensus piece in place first, then we can iterate and validate the behavior afterward #Cortensor #DevLog #Validate #Consensus #RouterNode #AgenticAI

🛠️ DevLog – Router Node - Added TaskEnded Wait Mode for Completions PR: github.com/cortensor/inst… We added the first part of the current /validate consensus-gap work: a new opt-in completion path that waits for the task to fully end instead of returning on the first committed result. This is still rough code for now and is mainly meant to prepare the completion flow for better consensus handling later. 🔹 What changed - Added a new opt-in completion flag - When enabled, router skips early return on TaskCommitted - Instead, it waits for TaskEnded and then pulls the task results afterward 🔹 Why this matters - The earlier gap was that the faster completion path could return too early, which is not ideal for validation-style flows where we want to see the fuller result set. - This new wait mode gives the router a better terminal point, especially when there are partial failures or mixed miner outcomes. 🔹 What this enables - Router can pull all committed task results through the batch web3 path - That includes offchain-backed results as well - This becomes the foundation for a later router-side consensus step 🔹 Current status - This is the first part of the /validate consensus-gap work - Rough code only for now - Main goal here is to get the completion flow into a better shape before adding the actual consensus aggregation helper next #Cortensor #DevLog #Validate #Consensus #RouterNode #AgenticAI

🛠️ DevLog – More Iteration on v3 /validate Consensus Gap As a follow-up to the earlier /validate consensus gap, the work is now shaping into two clearer parts. 🔹 Part 1: better task-end handling - The first part was adding a new opt-in path so v2/v3 can tell the shared completion flow not to return on the first committed result. - When that flag is enabled, the router waits until the task is actually finished, then pulls the task results afterward. - This gives a better terminal point for partial-failure cases and lets the router see the full available result set instead of only the first result. 🔹 Part 2: consensus helper - The second part is the actual consensus step. Once the router can wait for the task to fully end and see the available outputs, it still needs a small router-side helper that can turn those results into one final answer. - That is the part that would combine results into something like a majority verdict, average score, or another consensus-style response. 🔹 Current status - The first part is now done and should be pushed to the installer repo later today after the build. - Once that first piece looks okay, we’ll think more carefully about the second part. 🔹 Why this matters So the gap is becoming clearer now: first make sure /validate waits for the right endpoint, then add the logic that actually turns multiple results into a meaningful consensus answer. #Cortensor #DevLog #Validate #Consensus #AgenticAI #RouterNode

🛠️ DevLog – Wrapping Up the First Matrix / Stress-Test Phase for MVP Data Management We’re now wrapping up the current first phase of matrix tests and stress tests on the MVP data-management features. 🔹 Current result So far, the main privacy + offchain storage v3 combinations are holding up well and look stable through the current round of matrix and stress-style checks. 🔹 Current conclusion For now, we’re reasonably comfortable concluding that the current MVP data-management features look stable at the feature level across the main combinations we wanted to recheck. 🔹 What’s next We’ll still continue doing more tests in the coming weeks, but the next step is to move some of this into more regular repeated checks rather than only one-off test passes. 🔹 Daily test direction - We’ll likely ask some node operators/testers to help run these tests on a daily basis like we did before. - The goal there is to make sure the flows and router nodes stay stable over traffic and repeated usage, not just through isolated validation passes. 🔹 Practical setup That will likely involve running curl-triggered test requests daily so we can keep checking whether the core privacy/offchain MVP paths continue to behave correctly over time. #Cortensor #DevLog #Privacy #OffchainStorage #DataOwnership #Dashboard

🛠️ DevLog – Wrapping Up the Current MVP Data-Management Matrix Tests We’re now roughly wrapping up the current matrix-test round for the MVP data-management features. 🔹 Current result So far, the main permutations and matrix combinations are working as intended. Across the current combinations of privacy mode, node type, scope, and offchain storage v3 path, the essential flows are functioning in the way we expected. 🔹 What this covers This includes the broader combinations across: - public / private - dedicated / ephemeral - session scope / task scope - offchain storage v3, including deferred write for ephemeral nodes - single and multiple-node style paths 🔹 What this means - For now, the MVP data-management layer is holding up across the main combinations we wanted to recheck. - That gives us a good base for the current phase and confirms that the essential mixed paths are working, not just the isolated feature paths. 🔹 What’s next - We’ll keep doing more testing in the coming weeks, and we’ll likely still find more refinements, issues, and bug fixes during the rest of this phase. - But for now, the main matrix paths are functioning as intended. #Cortensor #DevLog #Privacy #OffchainStorage #DataOwnership #Dashboard

🛠️ DevLog – Rolling Out the Latest v3 /delegate on Testnet1a We’re now rolling out the current latest v3 /delegate path on testnet1a and starting to test a wider range of delegate cases there. 🔹 Current context Over the last stretch, a lot of the work was on MVP data-management features like privacy and offchain storage v3. With that current matrix round now in a better place, we can shift more attention back toward the router-node agentic surface as planned. 🔹 What’s being rolled out This is the current latest v3 /delegate shape we’ve been iterating on, including the more recent changes around normal task execution, router-assisted execution, and the rough planning/workflow split. 🔹 What we’ll be testing We’ll start testing different delegate-style cases more directly on testnet1a, including: - planning-style requests - direct execution-style requests - router-assisted fetch/read style requests - workflow/tool-assisted paths where applicable 🔹 Why this matters - The goal here is to move beyond just wiring/setup and start checking how the current v3 /delegate behavior actually holds up across different request types. - That should give us a better sense of where the current logic is already usable and where more iteration is still needed. 🔹 Current status Still very much in iteration stage, but this is the next practical step as we keep shaping /delegate into a more useful agentic surface on the router node. #Cortensor #DevLog #Delegate #AgenticAI #RouterNode #Testnet1a

🛠️ DevLog – More Iteration on What v3 /delegate Can Already Do As we keep shaping the v3 /delegate surface, the current rough behavior is becoming clearer. This part is not fully tested end to end yet, but based on the current implementation and some dev-side checks, these are the main things it can already do in rough form. We’ll be testing these more fully in the coming week once the current MVP data-management work for this week is wrapped up. 🔹 Planning mode When the request is asking how work should be handled rather than asking for direct execution, /delegate can already work in a planning-style mode, including: - delegation plan, workflow design, routing strategy - validation plan, rollout plan, incident investigation plan - research plan, decision / recommendation framework 🔹 Execution mode When the request is more like “do this task and give me the answer,” /delegate can already support rough direct task execution such as: - summarize, extract, classify, rewrite, compare - facts / entities / URLs / action items / deadlines extraction - risk review, checklist generation, incident triage - structured extraction, policy / decision support - lightweight synthesis, long-text chunk / summarize / reduce 🔹 Router-assisted execution It can also do router-assisted work where the router gathers context first, then returns the result. In rough form, that includes: - fetch one URL and summarize / extract / risk review - fetch one URL and produce release-note or operator-note style output - read external content, then synthesize - read offchain content and explain / summarize - read safe onchain state and explain / summarize 🔹 Workflow / tool mode If workflow mode is explicitly enabled, /delegate can also use a router-side tool path. Current rough tool groups include: - fetch / search: fetch_url, web_search - structured data: json_extract, json_merge, json_schema_validate, csv_parse - text utilities: text_stats, extract_urls, text_chunk_map_reduce, rerank - helpers: calculator, hash_text, dedupe_items, sort_items, datetime_now - execution / reads: validate_result, offchain_write, offchain_read, web3_read 🔹 Practical mental model A simple way to think about it right now is: - planning mode = tell me how this should be handled - execution mode = do the task and return the answer - workflow/tools mode = router can orchestrate tools before returning the answer 🔹 What’s next - So far, this is what we know v3 /delegate should be able to do in rough form. - It is not fully tested yet, but some of these paths have already been dev-tested. In the coming week, we’ll start testing these more fully once this week’s MVP data-management work is done. #Cortensor #DevLog #Delegate #AgenticAI #RouterNode #DePIN

🛠️ DevLog – More Iteration on What v3 /delegate Can Already Do As we keep shaping the v3 /delegate surface, the current rough behavior is becoming clearer. This part is not fully tested end to end yet, but based on the current implementation and some dev-side checks, these are the main things it can already do in rough form. We’ll be testing these more fully in the coming week once the current MVP data-management work for this week is wrapped up. 🔹 Planning mode When the request is asking how work should be handled rather than asking for direct execution, /delegate can already work in a planning-style mode, including: - delegation plan, workflow design, routing strategy - validation plan, rollout plan, incident investigation plan - research plan, decision / recommendation framework 🔹 Execution mode When the request is more like “do this task and give me the answer,” /delegate can already support rough direct task execution such as: - summarize, extract, classify, rewrite, compare - facts / entities / URLs / action items / deadlines extraction - risk review, checklist generation, incident triage - structured extraction, policy / decision support - lightweight synthesis, long-text chunk / summarize / reduce 🔹 Router-assisted execution It can also do router-assisted work where the router gathers context first, then returns the result. In rough form, that includes: - fetch one URL and summarize / extract / risk review - fetch one URL and produce release-note or operator-note style output - read external content, then synthesize - read offchain content and explain / summarize - read safe onchain state and explain / summarize 🔹 Workflow / tool mode If workflow mode is explicitly enabled, /delegate can also use a router-side tool path. Current rough tool groups include: - fetch / search: fetch_url, web_search - structured data: json_extract, json_merge, json_schema_validate, csv_parse - text utilities: text_stats, extract_urls, text_chunk_map_reduce, rerank - helpers: calculator, hash_text, dedupe_items, sort_items, datetime_now - execution / reads: validate_result, offchain_write, offchain_read, web3_read 🔹 Practical mental model A simple way to think about it right now is: - planning mode = tell me how this should be handled - execution mode = do the task and return the answer - workflow/tools mode = router can orchestrate tools before returning the answer 🔹 What’s next - So far, this is what we know v3 /delegate should be able to do in rough form. - It is not fully tested yet, but some of these paths have already been dev-tested. In the coming week, we’ll start testing these more fully once this week’s MVP data-management work is done. #Cortensor #DevLog #Delegate #AgenticAI #RouterNode #DePIN

🛠️ DevLog – Roughly What v3 /delegate Can/Will Do As we keep iterating on v3 /delegate, the rough shape is becoming clearer. At a high level, /delegate is meant to be a task-execution endpoint for prepared work and router-assisted work, while also keeping a separate planning-style mode when the request is really about how the task should be handled. 🔹 Core idea /delegate is basically for “do this task for me.” It can work on text/context already provided by the caller, or use router-side fetch/read steps first, then return the final result instead of just a plan. It can also shift into planning mode when the goal is to define how work should be routed, validated, or executed before doing it. 🔹 Execution mode In execution mode, /delegate is focused on producing the actual output. This can include: - fetch + summarize, extract, compare, research, or risk review - text work like extract, classify, rewrite, compare, or structured extraction - operational outputs like checklist generation, triage, policy/decision support, lightweight synthesis, and map-reduce style text work - tool-backed tasks where router-side fetch/read steps gather context first, then the final answer is returned 🔹 Planning mode In planning mode, /delegate is less about doing the task immediately and more about shaping how it should be done. This can include: - delegation plan, workflow design, routing strategy, validation plan - rollout plan, incident plan, research plan, tool plan - decision frameworks for choosing between alternatives before execution starts 🔹 Why this matters This makes /delegate more flexible than a simple planning-only surface. It can either execute the work and return the result, or help structure how the work should be handled first, depending on the request. 🔹 Current status Still rough and still being iterated, but this is the general feature direction we’re shaping for v3 /delegate right now. Examples: - dashboard-testnet1a.cortensor.network/session/120/38 - dashboard-testnet1a.cortensor.network/session/120/39 #Cortensor #DevLog #Delegate #AgenticAI #RouterNode #DePIN

🛠️ DevLog – Recap on MVP Data-Management Matrix Tests We’ve been running through a broader matrix of MVP data-management tests to recheck how privacy and offchain storage v3 behave across different node types, privacy settings, and result paths. 🔹 Current matrix paths - private + ephemeral + offchain v3: dashboard-testnet1a.cortensor.network/session/136 - public + ephemeral + offchain v3: dashboard-testnet1a.cortensor.network/session/137 - private + dedicated + offchain v3: dashboard-testnet1a.cortensor.network/session/138 - ephemeral + offchain v3 + multiple: dashboard-testnet1a.cortensor.network/session/139 - dedicated + offchain v3 + multiple: dashboard-testnet1a.cortensor.network/session/141 - private + ephemeral + offchain v3 + task-scope privacy: dashboard-testnet1a.cortensor.network/session/143/ta… - private + dedicated + offchain v3 + task-scope privacy: dashboard-testnet1a.cortensor.network/session/144/ta… 🔹 What this covers This matrix now spans public/private modes, ephemeral/dedicated paths, single/multiple miner behavior, and both session-scope and task-scope privacy combinations with offchain storage v3. 🔹 Current focus The goal here is not just to confirm that the core MVP paths work individually, but to surface mixed-path bugs, regression gaps, and dashboard friction when these features are combined in more realistic ways. 🔹 What’s next We’ll keep continuing these matrix tests, surface any remaining gaps, and keep refining the dashboard/UI/UX around privacy scope and offchain storage as we go. #Cortensor #DevLog #Privacy #OffchainStorage #DataOwnership #Dashboard

🛠️ DevLog – Looking More at Inference Quality Control Design One of the remaining quality gaps we still want to look at more is inference quality control for ephemeral nodes. We’ll spend a bit more time on rough design here now, then likely wrap more of it during the next phase or toward the end of this one. 🔹 Why this matters The goal is to improve routing and reliability based on recent functional behavior, not just whether a node looks statically available. 🔹 Current direction The current idea is fairly simple: introduce a dedicated oracle role tied to system-health ephemeral sessions. This health prover would periodically submit real tasks, check the input/output behavior, and record the results into a dedicated data module. 🔹 How it would be used Over time, that data can become another filter in node-pool selection for ephemeral nodes, so routing uses more recent functional quality as part of the decision. The same module could also feed into node performance and later reward logic as well. 🔹 Current status Still rough design thinking for now, but this is one of the last quality-control gaps we want to shape more clearly. #Cortensor #DevLog #InferenceQuality #EphemeralNodes #NodePool #DePIN

🗓️ Weekly Focus – Phase #3 Support, v3 /delegate & /validate Iteration & MVP Data Management Testing 🔹 Phase #3 – Support, Monitoring & Stats - Continue active monitoring across routing, miners, validators, dashboards, and L3 stats. - Track stability as more features move into deeper testing. 🔹 v3 /delegate + /validate – Iteration - With last week’s prep done, we’ll now iterate more deeply on /delegate and /validate to make them more solid. - Focus on real delegation/validation paths, routing behavior, and closing logic gaps from early tests. 🔹 Privacy Feature 1.0 – Regression Testing - Run deeper regression on session-scope and task-scope encryption. - Cover both dedicated-node and ephemeral-node paths again to confirm stability. 🔹 Offchain Storage v3 – Regression Testing - Run deeper regression on dedicated-node and ephemeral-node storage flows, including deferred writes. - Re-check storage behavior and operator-configured offchain paths. 🔹 MVP Data Management – Full E2E Tests - After testing each feature separately, run combined privacy + offchain end-to-end tests again. - Goal: confirm the full MVP stack works consistently across dedicated, ephemeral, router, miner, and dashboard flows. 🔹 Dashboard – UI/UX Refinement - Keep refining dashboard UX around privacy scope and offchain storage so these flows are easier to use in practice. 🔹 Inference Quality Control – Rough Design - Spend a bit of time on rough design for ephemeral-node inference quality control using real task probes and sliding-window stats. - Goal: improve routing and reliability based on recent functional behavior, not just static availability. This week is about pushing the MVP data-management stack through a more serious validation cycle, tightening v3 agent surfaces, and doing early design work on inference quality control. #Cortensor #Testnet #Phase3 #AIInfra #DePIN #Corgent #Bardiel #Delegate #Validate #PrivateAI #L3

🗓️ Weekly Focus – Phase #3 Support, v3 /delegate & /validate Iteration & MVP Data Management Testing 🔹 Phase #3 – Support, Monitoring & Stats - Continue active monitoring across routing, miners, validators, dashboards, and L3 stats. - Track stability as more features move into deeper testing. 🔹 v3 /delegate + /validate – Iteration - With last week’s prep done, we’ll now iterate more deeply on /delegate and /validate to make them more solid. - Focus on real delegation/validation paths, routing behavior, and closing logic gaps from early tests. 🔹 Privacy Feature 1.0 – Regression Testing - Run deeper regression on session-scope and task-scope encryption. - Cover both dedicated-node and ephemeral-node paths again to confirm stability. 🔹 Offchain Storage v3 – Regression Testing - Run deeper regression on dedicated-node and ephemeral-node storage flows, including deferred writes. - Re-check storage behavior and operator-configured offchain paths. 🔹 MVP Data Management – Full E2E Tests - After testing each feature separately, run combined privacy + offchain end-to-end tests again. - Goal: confirm the full MVP stack works consistently across dedicated, ephemeral, router, miner, and dashboard flows. 🔹 Dashboard – UI/UX Refinement - Keep refining dashboard UX around privacy scope and offchain storage so these flows are easier to use in practice. 🔹 Inference Quality Control – Rough Design - Spend a bit of time on rough design for ephemeral-node inference quality control using real task probes and sliding-window stats. - Goal: improve routing and reliability based on recent functional behavior, not just static availability. This week is about pushing the MVP data-management stack through a more serious validation cycle, tightening v3 agent surfaces, and doing early design work on inference quality control. #Cortensor #Testnet #Phase3 #AIInfra #DePIN #Corgent #Bardiel #Delegate #Validate #PrivateAI #L3