помоему она для этого подойдет лучше остальных

у меня есть зависимости одни полей от других

Чем? Если заполнение полей, то это по-моему чистой воды реляционка: поле - значение.

зависимость одного поля от значения другого

Какого рода зависимости?

короче, нужно доработать, чтобы можно было п

А давайте что ли релиз - вот вам небольшой проект, который поможет отправить уведомление о прохождении автотестов в telegram, slack, emal, mattermost, skype (//todo)
Поддерживаемые языки - en, fr, ru, ua (ждем ваши пулреквесты на новые локали)
И, конечно, не зависимо от CI - Jenkins, Teamcity, Github Actions - без разницы
https://github.com/qa-guru/allure-notifications

будет ли это поле вообще и если это дропдаун то какие в нем будут опции

Это другая таблица в реляционке (например). Ничего графового тут нет.

зависимости то какраз есть

прохождение флоу в котором сотни полей которые или появятся или не появятся и какие они значение будут принимать

чем не граф

Зависимость есть, но она не графовая. В общем, хотите зачем-то прикручивать графы -- ищите доки по конкретным графовым базам. Но это будет ваше собственное уникальное решение.

перенимаю сейчас один из проектов на java+selenium, где все степы обернуты в try-catch, где в catch отлов nosuchelementexception. Никаких ПО и ПФ нет и в помине. В первый раз сталкиваюсь с таким, но в целом поинмаю что обработка ошибки идет для менеджмента. Думаю внедрить selenide + po. Как в таком случае быть с NSEE? забить?

выглядит как будто вы хотите переложить логику прохождения тестов (генерацию данных для них) на структуру хранения. Выглядит стремновато

именно так

у меня нет другого выбора

Граф это "карта"-- задачи связанные с путями или связями.

"Прохождение флоу" -- это алгоритмическая задача "на таком-то шаге проверяем такое-то". Строить граф по ней нет необходимости, это структура вида "тест такой-то, шаг такой-то, сущности такие-то, значения такие-то".

В такой структуре мы можем спокойно проверять что значение 34 = 2 * (значение 3  + значение 4), но графы для этого совершенно не нужны, шагов достаточно.

Так в графах же суть в том, что каждая сущность связана с родительским узлом и там же связана с дочерними сущностями этого же родительского узла.
А если просто много записей, которые генерируются на определенных условиях, то это не граф. Это просто логика генерации полей.

Тысячи возможных комбинаций  я не буду каждую описывать