# Responsibility and Non-goals

Level: Intermediate

## Summary

Flow Core owns graph execution, typed data access, visual authoring, runtime binding, and supported extension contracts. Your project owns gameplay rules, networking, save policy, UI layout, content meaning, and the code that integrates Flow Core with the rest of the game.

This boundary is important because Flow Core is a behavior orchestration layer. It should make project behavior readable and debuggable without silently becoming every system in the project.

## Why It Exists

Clear ownership prevents hidden behavior. If Flow Core tried to infer networking, convert every value shape, own all UI rules, or run graph logic from arbitrary threads, the graph would become harder to reason about and harder to profile.

The responsibility boundary keeps the runtime predictable:

* Designers can inspect graph structure and Blackboard paths.
* Programmers can extend stable surfaces without depending on internals.
* Runtime data stays typed and explicit.
* Performance risks are visible enough to profile and fix.

## Mental Model

Treat Flow Core as the layer that answers three questions:

| Question                     | Flow Core answer                                                      | Project answer                                    |
| ---------------------------- | --------------------------------------------------------------------- | ------------------------------------------------- |
| What starts behavior?        | Entry, Trigger, or supported runtime call.                            | When the game should request that start.          |
| What data does behavior use? | Blackboard, payload, Target, or explicit value source.                | What the value means in the game.                 |
| What happens next?           | Graph branches, Guards, Instructions, Conditions, and node semantics. | The actual gameplay rule and content consequence. |

For example, Flow Core can route an interaction chain from a focused target. Your project decides whether that target opens a shop, starts dialogue, unlocks a door, or fails because the player lacks an item.

## Behavior Contract

Flow Core is responsible for:

* Building graph runtimes through `FlowCoreProcess`.
* Binding Local, Scene, and Global Blackboard scopes.
* Starting chains from Entries, Triggers, and supported runtime APIs.
* Evaluating Guards and node return semantics.
* Running registered Instructions and Conditions.
* Providing editor workflows for graph authoring, Debug Context, settings, and registries.
* Providing supported extension points such as custom Instructions, Conditions, custom types, and persistence handlers.

Flow Core is not responsible for:

* Network replication.
* Save-file format or save-slot policy.
* Inventory, quest, dialogue, combat, or economy rules.
* UI layout and screen navigation frameworks.
* Automatic conversion between arbitrary runtime types.
* Multithreaded graph execution.
* Replacing every C# system in the project.

## Design Implications

When a workflow crosses the boundary, keep each side explicit. A dialogue system can call a Flow Core Entry, and the graph can run animation, interaction, or UI signal logic. The dialogue database and conversation state still belong to the dialogue system.

When adding extensions, document which side owns each failure mode. A custom Instruction should state what it does when a target is missing, a Blackboard key has the wrong type, or the external system is unavailable.

When debugging, avoid treating Flow Core as the cause of every symptom. First identify whether the issue is graph execution, data binding, extension code, or the external system called by the graph.

## Common Misunderstandings

* "Flow Core should know my gameplay rules." It provides the routing and execution surface; your project defines the rule.
* "Global Blackboard is the easiest shared state." It is the broadest shared state and should be used deliberately.
* "If a value exists in code, any node can read it." The graph needs an explicit value source or supported extension.
* "A generated member is automatically a public design contract." Generated output can help authoring, but the project still decides which APIs are stable for designers.
* "A graph can safely mutate runtime lists from any thread." Runtime graph work should be coordinated on Unity's main thread.

## Related

* [What Is Flow Core](/flow-core-docs/documentation/core-concepts/what-is-flow-core.md)
* [Design Levers](/flow-core-docs/documentation/core-concepts/design-levers.md)
* [Lifecycle and Dataflow](/flow-core-docs/documentation/runtime-guide/lifecycle-and-dataflow.md)
* [Extension Points](/flow-core-docs/documentation/api-extension-guide/extension-points.md)
* [Performance and Failure Modes](/flow-core-docs/documentation/troubleshooting/performance-and-failure-modes.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://flow-core.gitbook.io/flow-core-docs/documentation/core-concepts/responsibility-and-non-goals.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.