Какие исходные данные нужны для разработки проекта

Исходных данных достаточно для начала проектирования тогда, когда по каждому решению, которое предстоит принимать на текущей стадии, существует подтверждённое основание либо явно зафиксировано допустимое временное допущение. Поэтому правильный исходный пакет — это не максимально большой архив документов и не универсальный перечень файлов. Его формируют от будущих проектных решений: сначала определяют, что именно нужно разработать, затем устанавливают, какие параметры влияют на эти решения, и только после этого проверяют наличие, источник и актуальность каждого параметра.

В исходный пакет обычно входят техническое задание, исходные требования заказчика, технические условия и доступные исходно-разрешительные материалы, сведения о площадке или существующем объекте, а также результаты инженерных изысканий и обследований в той части, в которой они необходимы для принимаемых решений. Но наличие документов само по себе ещё не означает готовность к проектированию. Важно понять, подтверждают ли они именно те значения и ограничения, которые проектировщик будет использовать.

Что считать исходными данными

Исходные данные — это подтверждённые требования, параметры, ограничения и сведения о существующих условиях, на основании которых принимаются проектные решения. Их функция состоит не в том, чтобы формально укомплектовать папку, а в том, чтобы дать проектировщику достоверную основу для конкретного выбора, расчёта, размещения или технической разработки.

Один документ может содержать сразу несколько исходных параметров. И наоборот, один проектный параметр иногда приходится подтверждать несколькими материалами. Поэтому полезнее рассматривать исходные данные не как перечень названий документов, а как совокупность необходимых проекту фактов.

Например, для конкретного решения может потребоваться установить:

• назначение и функциональную задачу объекта;
• требования заказчика к будущему результату;
• положение объекта и исходные характеристики площадки;
• параметры существующего здания или сооружения, если проект с ним взаимодействует;
• условия подключения или взаимодействия с внешними системами;
• результаты инженерных изысканий или обследований, влияющие на решение;
• геометрические, технические или эксплуатационные ограничения;
• уже согласованные изменения исходных требований.

Если такой параметр существует только как предположение проектировщика, его нельзя незаметно приравнивать к подтверждённому исходному факту. Допущение допустимо использовать как отдельное рабочее состояние, но должно быть понятно, что именно принято временно и какие решения потребуется перепроверить после уточнения.

Начинать нужно не с перечня файлов, а с перечня решений

Самый практичный способ определить достаточность исходных данных — сначала разложить будущую работу на решения, которые предстоит принять. Для каждого решения затем устанавливают его входные параметры.

Например, если требуется разработать размещение оборудования, проектировщику может быть недостаточно одного общего задания. Понадобятся параметры самого оборудования, сведения о доступном пространстве, геометрические ограничения и данные, определяющие его взаимодействие со смежными системами. Для другого решения набор исходных условий будет иным.

Так формируется зависимость:

проектное решение → необходимые параметры → документальный источник → статус исходных данных.

Эта последовательность защищает от двух противоположных ошибок. Первая — начать проектирование при отсутствии критичного основания. Вторая — задерживать начало работы из-за документов, которые для текущей стадии вообще не влияют на принимаемые решения.

Техническое задание

Техническое задание задаёт исходную постановку задачи: что должно быть спроектировано, какое назначение имеет объект и какие требования заказчика должны быть учтены. Для практической работы важно не только наличие файла под названием «техническое задание», но и его содержательная пригодность.

Проектировщику должно быть понятно:

• каков предмет проектирования;
• какие решения входят в текущую задачу;
• какие исходные требования считаются зафиксированными;
• какие ограничения или пожелания заказчика действительно влияют на решения;
• какие вопросы пока остаются открытыми.

Если техническое задание сформулировано слишком общо, часть параметров фактически начинает определяться уже в процессе проектирования. Это не обязательно блокирует начало работы, но такие параметры нужно выделить отдельно, иначе временное предположение постепенно начинает восприниматься как утверждённое исходное условие.

Особое внимание требуется после изменения задания. Если первоначальные требования уже использованы в расчётах или чертежах, новая редакция должна быть сопоставлена с ранее принятыми решениями. Иначе в проекте одновременно останутся решения, основанные на разных состояниях исходной задачи.

Исходные требования заказчика

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

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

Поэтому требования полезно фиксировать не только текстом, но и связью с решениями: какое требование на что влияет. Тогда при его изменении понятно, какие расчёты и чертежи требуется вернуть в работу.

Если же требование имеет пожелательный характер и не влияет на текущий этап, его можно оставить за пределами критичного исходного пакета до момента, когда оно станет проектно значимым.

Сведения о площадке

Проект должен использовать актуальные сведения о территории, на которой размещается объект. В зависимости от задачи могут иметь значение положение объекта, существующая ситуация, геометрия участка, рельеф, расположение существующих сооружений и другие площадочные условия.

Достаточность таких данных оценивают относительно конкретного решения. Например, для предварительной проработки может быть достаточно одной степени детализации, а для решения, которое зависит от точной геометрии или условий площадки, потребуется более подтверждённая исходная основа.

Ключевой вопрос — можно ли по переданным данным принять текущее решение без скрытого предположения о фактических условиях. Если нельзя, нужно либо получить недостающие сведения, либо явно зафиксировать временное допущение и границу его применения.

При изменении положения объекта необходимо проверить пространственную применимость ранее полученных данных. Исходный документ может оставаться актуальным для одной части площадки и одновременно быть недостаточным для другой зоны, появившейся после корректировки.

Сведения о существующем объекте

Если проект связан с уже существующим зданием, сооружением или системой, исходной основой становятся данные о фактическом состоянии объекта. Здесь особенно опасно подменять подтверждённую информацию проектными предположениями.

Для разных решений могут потребоваться:

• фактическая геометрия;
• расположение существующих элементов;
• характеристики конструкций или систем;
• сведения о выявленном состоянии;
• результаты обследований в необходимом объёме;
• имеющаяся документация на существующий объект.

Наличие старых чертежей само по себе ещё не подтверждает фактическое состояние. Если новое решение зависит от реального размера, положения или характеристики существующего элемента, нужно понимать источник этого значения и степень его актуальности.

Если часть сведений пока не подтверждена, проектирование некоторых решений может продолжаться условно. Но должна существовать ясная граница: какие решения допускают дальнейшую разработку, а какие нельзя окончательно фиксировать до получения фактических данных.

Технические условия

Технические условия используются как исходное основание там, где проектное решение зависит от внешнего подключения, параметров взаимодействия или других условий, задаваемых вне самого проектируемого объекта.

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

Если часть технических условий ожидается позже, это не всегда означает, что весь проект должен быть остановлен. Нужно разделить решения на зависимые и независимые. Независимые части могут разрабатываться дальше. По зависимым решениям следует либо отложить окончательный выбор, либо использовать явно обозначенное временное допущение с последующей обязательной проверкой.

Опасной становится ситуация, когда ожидаемое условие не оформлено как открытый вопрос, а временное значение незаметно используется во всех последующих документах. Чем дальше распространяется такое значение, тем больше объём повторной корректировки при его изменении.

Исходно-разрешительные материалы

Доступные исходно-разрешительные материалы рассматривают по их фактическому влиянию на проект. Не требуется механически включать в критичный пакет каждый возможный документ только потому, что он существует в проектном процессе.

Для каждого материала задают вопрос: какое ограничение или исходное условие он подтверждает и какое проектное решение от этого зависит. Если связь существует, документ становится частью исходного основания для соответствующего решения.

Если документ не влияет на текущую стадию, его отсутствие может не препятствовать началу именно этой части проектирования. Но как только связанное решение входит в работу, статус исходного материала нужно пересмотреть.

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

Инженерные изыскания

Результаты инженерных изысканий нужны не «в целом для проекта», а как источник определённых параметров площадки и природных условий, которые используются конкретными проектными решениями.

При подготовке исходного пакета проверяют:

• какие виды данных фактически требуются для текущих решений;
• есть ли соответствующие результаты;
• относятся ли они к нужной территории;
• какая версия материалов является актуальной;
• какие параметры из отчётов должны перейти в расчёты и чертежи.

Если исследование выполнено, но его результаты не применимы к новой зоне объекта или не содержат параметра, ставшего значимым после изменения проекта, наличие отчёта не делает исходный пакет достаточным автоматически.

В то же время отсутствие части изысканий не означает, что нельзя начать никакую проектную работу. Следует определить, какие решения от них зависят. Независимые задачи могут продолжаться, а зависимые получают условный статус.

Обследования существующего объекта

Обследования становятся исходной основой для тех решений, которые зависят от состояния существующих элементов. Объём необходимой информации определяется не самим фактом реконструкции или работы с существующим объектом, а конкретными проектными решениями.

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

При ограниченном объёме обследований полезно составить карту покрытия: какие решения имеют подтверждённые данные, а какие пока основываются на предположении. Такая карта позволяет проектировать последовательно и не создавать ложного впечатления полной исходной определённости.

Матрица «данные → решение»

Для сложного проекта удобно использовать матрицу «данные → решение». Это рабочая таблица, в которой по каждому проектному решению фиксируют необходимый исходный параметр, источник, актуальную версию и статус достаточности.

Проектное решение	Необходимый исходный параметр	Источник	Статус	Последствие пробела
Решение А	Подтверждённый параметр площадки	Актуальный исходный документ	Подтверждён	Решение может разрабатываться на установленной основе
Решение Б	Условие внешнего взаимодействия	Технические условия ожидаются	Открыт	Окончательная фиксация зависимого решения откладывается
Решение В	Характеристика существующего объекта	Предварительные сведения	Допущение	После обследования потребуется повторная проверка

Смысл матрицы не в создании ещё одного формального реестра. Она отвечает на практический вопрос: какое решение можно принимать сейчас, какое требует дополнительного документа и где временное предположение уже влияет на проект.

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

Контроль источника каждого параметра

Любое значимое исходное значение должно иметь понятное происхождение. Если параметр встречается в расчёте или чертеже, полезно уметь ответить, из какого документа или подтверждённого решения он получен.

Возможны несколько состояний:

• значение подтверждено актуальным документом;
• значение подтверждено, но документ относится к предыдущей версии;
• значение взято из другого согласованного источника;
• значение принято как временное допущение;
• происхождение значения установить невозможно.

Последние два состояния нельзя объединять. Зафиксированное допущение — управляемая неопределённость: известно, что именно требует дальнейшего подтверждения. Параметр неизвестного происхождения — неконтролируемая неопределённость, потому что непонятно даже, почему проект использует именно это значение.

Актуальность документа

Версия документации — это конкретное состояние документа после определённого набора изменений. Для исходных данных важно не просто иметь нужный документ, а удостовериться, что проект использует его актуальное состояние.

Например, техническое задание могло быть уточнено после начала работы, технические условия — заменены новой редакцией, а исходный план площадки — обновлён после дополнительных данных. Если проектировщик продолжает использовать предыдущую версию, исходный пакет формально полный, но фактически несогласованный.

Поэтому контроль актуальности должен отвечать на три вопроса:

1. какая версия документа считается действующей для текущего решения;
2. какую версию фактически использовал проектировщик;
3. менялись ли между версиями параметры, влияющие на проект.

Если изменения между редакциями не затрагивают проверяемый параметр, не требуется автоматически считать прежний вывод неверным. Если изменилось именно исходное значение, зависимые решения нужно пересмотреть.

Реестр допущений

Когда проектирование начинается до полной готовности исходного пакета, полезно вести отдельный реестр допущений. В него включают не все открытые вопросы подряд, а те временно принятые значения, которые уже используются для разработки решений.

По каждому допущению желательно фиксировать:

• какое значение или условие принято временно;
• почему подтверждённые данные пока отсутствуют;
• какие решения используют это значение;
• насколько чувствителен результат к его изменению;
• какой документ или факт должен заменить допущение;
• что необходимо перепроверить после уточнения.

Так временное решение не маскируется под подтверждённое исходное основание. Проектировщик может продолжать часть работы, а заказчик видит, где остаются условия, способные вызвать последующую корректировку.

Допустимое и рискованное допущение

Не каждое отсутствие данных одинаково критично. Допущение можно считать управляемым, если его влияние ограничено, оно явно зафиксировано и существует понятный порядок проверки после получения окончательного значения.

Риск возрастает, когда временный параметр:

• определяет принципиальное техническое решение;
• используется несколькими дисциплинами;
• передаётся в расчёты, спецификации и рабочие чертежи;
• влияет на решения, которые вскоре станет дорого менять;
• не имеет понятного срока или способа подтверждения.

Чем шире распространяется такое значение, тем важнее получить подтверждённые данные раньше. Иначе один исходный пробел превращается в цепочку зависимых корректировок.

Часть технических условий ожидается позже

Если часть технических условий ещё не получена, нужно определить, какие конкретные проектные решения от них зависят. Нельзя одинаково блокировать все дисциплины только потому, что пакет исходных документов ещё не завершён.

Первую группу составляют решения, которые не используют ожидаемые параметры. Их можно разрабатывать дальше на подтверждённых данных.

Вторая группа — решения, которые можно прорабатывать предварительно, но нельзя окончательно зафиксировать без ожидаемого условия. Здесь допустимо использовать отдельно обозначенное предположение, если понятны границы его влияния.

Третья группа — решения, где без подтверждённого параметра выбор принципиально неопределён. Их окончательная разработка до получения исходного основания создаёт высокий риск последующей переработки.

Такое разделение позволяет продолжать проектирование осознанно, не выдавая частичную готовность исходных данных за полную.

Площадка известна, но инженерные условия ещё уточняются

В этой ситуации геометрическая и площадочная основа может быть уже достаточной для части решений, тогда как инженерные параметры остаются открытыми. Важно не смешивать эти два слоя.

Например, можно подтвердить положение объекта и часть планировочных решений, если они не зависят от ещё неизвестного инженерного параметра. Одновременно оборудование или система, выбор которых определяется будущими условиями, не должны считаться окончательно подтверждёнными.

В реестре исходных данных такие решения получают разные статусы. Это позволяет избежать ложной формулы «исходных данных либо достаточно для всего проекта, либо недостаточно вообще».

Проект начинается с ограниченным объёмом обследований

Ограниченное обследование может быть достаточным для начальной разработки только тех решений, которые реально покрываются полученными данными. Для остальных участков необходимо определить, какое неизвестное состояние остаётся и что произойдёт, если оно окажется другим.

Например, имеющихся сведений может быть достаточно для общей концепции размещения нового решения, но недостаточно для окончательной разработки сопряжения с существующим конструктивным элементом. В таком случае первая часть работы может продолжаться, а вторая остаётся зависимой от последующего обследования.

Важно не распространять результаты локального обследования на весь существующий объект без подтверждённого основания. Если данные относятся только к определённой зоне, именно эту пространственную границу нужно сохранять и в проектном выводе.

Как определить критичность недостающего параметра

Не все запросы недостающих данных имеют одинаковый приоритет. Для каждого пробела полезно оценить масштаб его влияния.

Приоритет повышается, если параметр:

• необходим для принципиального выбора решения;
• участвует в расчётной модели;
• используется сразу несколькими разделами;
• определяет геометрию или размещение большого числа элементов;
• влияет на будущую спецификацию или состав оборудования;
• после уточнения потребует значительного объёма переработки;
• нужен до ближайшей контрольной точки проекта.

Таким образом, запросы можно формировать не по принципу «собрать всё отсутствующее», а по влиянию на текущую работу. Сначала получают данные, которые разблокируют критичные решения или предотвращают крупную переработку.

Приоритет запросов на недостающую информацию

Практический реестр запросов удобно разделить на несколько уровней.

Приоритет	Характер пробела	Действие
Высокий	Без параметра нельзя выбрать или подтвердить ключевое решение	Получить или подтвердить данные до дальнейшей фиксации зависимой части проекта
Средний	Работу можно продолжать по явному допущению, но потребуется повторная проверка	Зафиксировать допущение, зависимые решения и срок уточнения
Низкий для текущей стадии	Документ понадобится позже и не влияет на принимаемые сейчас решения	Не блокировать текущую работу, но сохранить его в плане исходных данных

Такой подход делает управление исходными данными частью проектного планирования. Видно не только, чего нет, но и почему отсутствие конкретного документа важно именно сейчас.

Как отличить недостаток исходных данных от ошибки проектировщика

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

Например, значение в проекте отличается от текущего исходного документа. Возможны как минимум три объяснения:

• проектировщик использовал неверное значение при наличии актуальных данных;
• проект выполнен по предыдущей версии документа, а исходные данные изменились позже;
• актуального значения на момент работы не было, и использовалось временное допущение.

Эти ситуации нельзя исправлять одинаково. В первом случае требуется корректировка решения. Во втором — актуализация после изменения исходных данных. В третьем — подтверждение или замена ранее зафиксированного допущения.

Как отличить устаревшую версию от содержательного несоответствия

Перед выводом об ошибке нужно проверить версии исходных и проектных документов. Если техническое задание, технические условия или исходная модель площадки были изменены после разработки расчёта, различие может объясняться историей проекта.

Сначала восстанавливают последовательность:

1. какая версия исходного документа использовалась при разработке;
2. какой параметр содержался в этой версии;
3. когда появился новый исходный документ;
4. изменился ли в нём именно параметр, влияющий на решение;
5. были ли после этого пересмотрены зависимые документы.

Если проект соответствует прежнему исходному состоянию, но не актуальному, нужно обновлять цепочку. Если же проект и исходные данные относятся к одной версии и всё равно содержат разные значения, появляется содержательное несоответствие.

Какие данные нужны не сразу

Достаточность всегда связана со стадией и перечнем решений. Документ, без которого нельзя завершить один этап, может не требоваться для предыдущей проработки.

Поэтому исходный пакет полезно разделять по моменту использования:

• данные, необходимые до начала конкретного проектного решения;
• данные, которые можно получить до его окончательной фиксации;
• данные, относящиеся к следующей стадии и не влияющие на текущую работу.

Это позволяет не требовать полного будущего комплекта в первый день проектирования и одновременно не откладывать получение критичных параметров до момента, когда на них уже построено множество зависимых решений.

Когда исходных данных действительно недостаточно

Критической недостаточность становится тогда, когда отсутствует подтверждённый параметр, способный изменить само решение, а допустимого управляемого допущения для продолжения работы нет.

Признаками такой ситуации являются:

• невозможно определить принципиальный вариант решения;
• расчёт зависит от неизвестного ключевого входного параметра;
• не подтверждена геометрия, от которой зависит размещение или сопряжение;
• отсутствует актуальная версия ключевого документа;
• разные исходные материалы содержат противоречащие значения, и невозможно установить действующее;
• временное предположение может привести к значительной переработке, если окажется неверным.

В таком случае правильнее зафиксировать невозможность окончательного вывода по конкретной части, чем продолжать разработку на скрытом предположении.

Что можно делать при частичной достаточности

Если исходный пакет готов не полностью, проектирование можно разделить по степени определённости.

Подтверждённые решения — имеют актуальное исходное основание и могут разрабатываться в обычном порядке.

Условные решения — могут прорабатываться при явно зафиксированном допущении, но требуют контрольной проверки после получения исходных данных.

Заблокированные решения — не должны окончательно приниматься, потому что отсутствующий параметр способен изменить их принципиально.

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

Реестр исходных данных

Практическим результатом подготовки должен стать структурированный реестр исходных данных. Он показывает не только наличие документов, но и фактическую достаточность для принимаемых решений.

Для каждой позиции удобно фиксировать:

• исходный параметр или требование;
• проектное решение, которое от него зависит;
• документ-источник;
• версию или актуальное состояние источника;
• статус: подтверждён, отсутствует, требует уточнения или используется как допущение;
• влияние недостатка данных;
• приоритет получения;
• перечень решений, которые потребуется повторно проверить после уточнения.

Такой реестр позволяет отличать простую комплектность документов от проектной готовности.

Проверка исходного пакета перед началом работы

1. Определить задачу и назначение объекта. Должно быть понятно, какие решения предстоит разработать на текущей стадии.
2. Разложить решения на исходные параметры. Для каждого решения определить необходимые требования, ограничения и фактические данные.
3. Найти документальный источник. Установить, чем подтверждается каждый существенный параметр.
4. Проверить актуальность. Убедиться, что используется действующая версия источника и что его параметры относятся к текущему состоянию проекта.
5. Проверить применимость. Особенно для данных площадки, изысканий и обследований установить, относятся ли они именно к проверяемой зоне или объекту.
6. Выделить пробелы. Зафиксировать отсутствующие документы и неподтверждённые параметры.
7. Сформировать реестр допущений. Отдельно обозначить временные значения, используемые для продолжения проектирования.
8. Оценить последствия пробелов. Понять, какие решения будут условными и что потребуется пересмотреть после уточнения.
9. Расставить приоритет запросов. Сначала получить сведения, которые влияют на наиболее критичные и зависимые решения.

После такой проверки можно осознанно определить, что действительно готово к разработке сейчас, а что должно ждать дополнительной исходной информации.

Как выглядит достаточный исходный пакет

Достаточный пакет не обязательно означает, что получены абсолютно все документы, которые когда-либо понадобятся проекту. Он означает, что для текущей совокупности решений известны исходные основания и нет неуправляемых пробелов.

Для каждого существенного решения должно быть понятно:

• какой исходный параметр используется;
• откуда он получен;
• актуален ли источник;
• подтверждено ли значение или принято временно;
• какие ограничения имеет такой статус;
• нужно ли возвращаться к решению после получения новых данных.

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

Что результат позволяет сделать

Структурированный реестр исходных данных позволяет начать проектирование с понятными ограничениями. Проектировщик видит, какие решения имеют подтверждённую основу, какие можно разрабатывать условно и какие следует отложить. Заказчик получает конкретный перечень недостающих данных с объяснением их влияния, а не абстрактный запрос «дослать исходную документацию».

Кроме того, становится проще управлять изменениями. Если позже меняется исходный параметр, по связи «данные → решение» можно быстро найти расчёты, чертежи и спецификации, которые необходимо перепроверить.

Реестр допущений помогает не потерять временные решения. После получения окончательного документа становится понятно, где нужно проверить соответствие нового значения первоначально принятому и требуется ли корректировка.

Граница достаточности

Единого универсального пакета исходных данных для любой проектной задачи нет. Достаточность зависит от стадии разработки, состава объекта и конкретных решений, которые требуется принимать сейчас. Один и тот же документ может быть критичным для одной части проекта и не иметь значения для другой.

Поэтому отсутствие некоторого будущего документа не следует автоматически считать препятствием для всей работы. Но и наличие большого комплекта материалов не гарантирует готовности, если в нём отсутствует один ключевой параметр, от которого зависит принципиальное решение.

Если актуальная версия ключевого документа отсутствует или не подтверждён исходный параметр, влияющий на решение, соответствующий проектный вывод должен оставаться условным. В таком случае нужно прямо указать, что именно требуется получить и какие документы придётся повторно проверить после уточнения.

Надёжная подготовка исходных данных поэтому строится не вокруг количества файлов, а вокруг прослеживаемости оснований. Для каждого текущего проектного решения должно существовать подтверждённое исходное условие либо явно управляемое допущение. Когда такая связь сформирована, можно начинать проектирование с понятным уровнем определённости, заранее видеть критичные пробелы и не скрывать неподтверждённые предположения под видом готовых исходных данных.