If there is a lot of 'hypothesising' and meeting without fixed time frames - it's more about that the scope of works is not clarified clearly yet. When the scope is cemented and timeline is prepared, but new requirements are coming or changing or meetings are delayed - we only proceed to work on already agreed scope, highlighting the delays for the Customer with options for trade-off, if he wants to deprioritize one feature in favour to another.
You can try SAFe framework (https://www.scaledagileframework.com/# and https://www.guru99.com/scaled-agile-framework.html) - I can highlight it on top of what other responders mentioned before. From many speakers on professional conferences arranged in Russia, this framework was highlighted many times as used in 'laboratory'(this term is used to name a mid or big-size team, focused on product development in not-well-known-yet area as we). Epic -> Feature -> User Story flow.
As you've mentioned that 'your PO is not an expert in the subject area' and that there is a 'a vast number of dependencies between stories. It's more like a flow chart or decision tree, then a story map', i found SAFe potentially suitable for use as it has Features and Feature owners, which become personally responsible for the E2E value, which the guys they rely on are experts in subject area and can provide business value + code.
The decomposition in SAFe is: Epic -> Architectural sub-epic (then breakdown to a Feature(s), which are split to Stories, which are split to Tasks in their turn) plus Business sub-epic (then breakdown to a Feature(s), which are split to Stories, which are split to Tasks in their turn).
My personal experience (business analyst on a large enterprise project, where for one of its phases we've used SAFe-like Feature-based approach in order to focus on the delivery of business value for a few, but scenarios-loaded topics).
Feature, is owned by business analyst which product's component is the most impacted (aka 'business owner' - responsible for E2E and for business value specifically) plus dev lead (aka 'technical owner' - orchestrates the development of all the stories, i.e. E2E within the Feature). Meanwhile 'business owner' is dependent on the implementation results owned by 'technical owner', 'business' is anyway the main one, as he finally demonstrates it to the Customer (externally or internal overall Product Owner -as in your case) and gathers the feedback.
Business Stories under the Feature, each one is owned by the business analyst (responsible for a particular scenario, i.e. functionality according to feature decomposition).
Once business stories are described and there is a visible E2E or solid part of it - kick-off for Technical Story Owner/Team is arranged.
Technical Stories under the Feature, each one is owned by dev lead (responsible for particular scenario, i.e. functionality according to feature decomposition) - in order to simplify reporting, DEV Team mirrored Technical Feature->Technical Stories, keeping the links to the ID of Business Story (speaking about JIRA).
Once technical stories are implemented and there is a visible E2E or solid part of it - DEMO for Business Story Owner/team is arranged.
I didn't highlight Epics as in this approach the 'Feature' was a more relevant term.
PROS: personal involvement and personal responsibility.
CONS: overhead for keeping an eye on technical tasks for a non-technical'business owner'.