Mental model
Six questions cover the customer-facing workflow model.
Viewport should feel simple because a workflow only needs to answer six questions.
The Six Questions
| Question | Product object | What it controls |
|---|---|---|
| What starts it? | Trigger | Slack mention, GitHub event, Linear/Jira issue, schedule, manual run |
| What repo(s) can it work on? | Repos | Operating repos, docs repos, read/write scope, checkout/publish authority |
| What context can it use? | Context Sources and Update Targets | Runbooks, docs, repo context, source refs, per-node reads, proposed updates |
| Who approves what? | Approvals | PM plan review, engineering review, PR approval, context update approval |
| What actions can it take? | Actions | Open PR, reply in Slack, comment/transition tickets, write approved docs updates |
| Where should it run? | Runner | Self-hosted or managed compute, agents, models, tools, MCPs, credential posture |
That is the customer model. Everything else is compiled implementation detail.
Defaults And Overrides
A workflow has defaults:
- default runner or runner tags;
- default operating repos;
- default context sources;
- default context update targets;
- default approvals;
- default allowed side effects;
- default budgets and timeouts.
Nodes inherit those defaults unless they override them:
- a planning node may read support runbooks but exclude repo implementation context;
- an implementation node may use the governed checkout and repo context;
- an approval node routes to PMs, engineers, security, or on-call;
- a context update node may propose changes only to allowed update targets.
Healthy defaults keep workflow creation fast. Overrides make individual steps auditable.
Authority Versus Capability
Keep this split clear:
Automations define the governed route-to-policy-to-run path.
Policies decide what the agent may touch and who must approve.
Runner pools decide where it can run.
Runners enforce the contract at execution time.Repo/context/action authority belongs to the automation/team policy. Runners do not become giant permission objects. A runner advertises capability:
- Claude/Codex/custom agents;
- agent-scoped models;
- git/node/npm/docker/gh tools;
- MCPs and local adapters;
- self-hosted or managed mode;
- context worker support;
- runner-local, runner-encrypted, or managed credential posture.
Viewport matches workflow requirements against runner capability before a run starts. If a runner cannot satisfy the workflow, the run should fail before execution with a clear reason.
Run Preparation
After a trigger matches a published workflow, Viewport prepares the run.
Run preparation does not clone every connected repo and does not inject every context source into every node. It materializes only what this run is allowed to touch:
- operating repos;
- context source refs;
- update target scopes;
- credential bindings;
- side-effect permissions;
- approval gates.
Preparation emits receipts. Node policy still decides what each step can see or do.
Receipts Are The Product
A useful run should answer:
- what source event started it;
- which workflow/version matched;
- which runner claimed it;
- which repos were prepared;
- which context sources were selected;
- what snippets/citations/digests were used;
- who approved or requested changes;
- which credential handle performed checkout/publish/action;
- what branch, commit, PR, Slack message, or docs proposal resulted;
- what audit packet proves it.
If the run page cannot answer those questions, the workflow is not explainable enough.
What To Read Next
- Workflows for how automations compile into durable execution records.
- Trust and privacy for data and credential boundaries.
- Inbox for the human-in-the-loop model.
- Team Context for context sources and update proposals.