01 — Preserve uncertainty
Missing data is not negative evidence.
Many automation failures begin with an innocent shortcut: a field is empty, so the system treats the answer as no. That is closed-world logic. It can be appropriate in a tightly controlled database, but it is dangerous when an agent is assembling evidence from incomplete resumes, websites, job descriptions or external sources.
OpportunityOS uses an open-world distinction in its public architecture: UNKNOWN is not FALSE, and ABSENT is not INELIGIBLE. If work authorization for one country is not recorded, that does not establish that the person is unauthorized there. If a tool is not mentioned in one document, that does not prove the person lacks it.
The practical consequence is that uncertainty must survive normalization. Once an ingestion layer collapses unknown into false, every downstream model inherits a confident fiction.
02 — Attach claims to evidence
Provenance has to constrain generation, not decorate it afterward.
A citation shown next to generated text is useful, but governance needs a stronger invariant: material claims should be generated only from facts the system is authorized to use. In OpportunityOS, the Truth Graph and EvidenceClaim model are the factual authority for founder claims.
The public product constitution permits generated CVs, proposals and related artifacts to select, reorder, summarize and rewrite verified facts. It does not permit them to invent employers, dates, titles, skills, credentials, achievements, outcomes or other material claims. If evidence is insufficient, the output should omit the claim or route it for review.
That design moves provenance upstream. Instead of asking 'Can I find a source that resembles what the model just wrote?', the compiler asks 'Which verified evidence permits this sentence to exist?'
03 — Separate qualification from guessing
A hard rejection should require a hard conflict.
Agents that rank opportunities face a tempting optimization: turn every unknown into a penalty so the pipeline can always produce a clean ordered list. The result looks decisive but can systematically reject opportunities for which the evidence is merely incomplete.
The OpportunityOS approach keeps hard constraints separate from soft ranking. A hard rejection needs an explicit requirement plus a verified conflict or applicable policy. Missing evidence can lower confidence, create a review task or remain an unknown, but it does not get promoted into a fact simply because the scoring function wants a number.
This is a broader governance pattern: uncertainty should affect confidence and workflow, not silently mutate ontology.
04 — Separate language ability from action authority
Being able to fill a form is not permission to submit it.
An agent can often generate an answer, navigate a page and identify a submit button long before the system has earned authority to make the external commitment. Treating those capabilities as one permission boundary is a serious design error.
OpportunityOS therefore exposes three action modes. DRY_RUN prepares and validates without external mutation. ASSISTED may navigate, fill or upload where allowed but must not submit. CONTROLLED_SUBMIT is reserved for individually graduated actions whose pre-submit checks and authority requirements have been satisfied.
This separation makes escalation explicit. It also creates a place for CAPTCHA, MFA, ambiguous declarations, changed terms or uncertain prior outcomes to stop the workflow rather than trigger improvisation.
05 — Treat uncertain side effects as state
After an ambiguous external action, do not guess and retry.
Distributed systems already teach this lesson: a timeout does not tell you whether the remote side effect happened. Agentic workflows inherit the same problem. If a submission request times out after the remote server accepted it, blindly retrying can create duplicate applications, messages or transactions.
A governed workflow needs an explicit uncertain-outcome state and a reconciliation path. The agent should freeze the affected action, inspect durable evidence where available, and recover deliberately. 'I did not see success' is not equivalent to 'nothing happened'.
This is another form of open-world reasoning: operational uncertainty deserves its own state rather than being coerced into a convenient boolean.
06 — Keep learning downstream of truth
Optimization must not create a weaker route around the authority model.
Outcome feedback can improve source selection, ranking and workflow efficiency. It should not rewrite historical facts, relax claim provenance or quietly widen action permissions because a reward signal says that doing so increases throughput.
In the public OpportunityOS architecture, monitoring and learning sit downstream of the same truth and authority contracts. That ordering matters. A learning loop can propose better behavior, but deterministic truth and permission invariants remain the boundary it has to operate within.
This is where governance becomes architecture rather than policy prose: the safest rule is the one a lower-level module cannot bypass by accident.
07 — Design for explainable restraint
A useful agent should be able to explain why it stopped.
A refusal to invent missing evidence is not a failure of autonomy. Neither is requiring review before a consequential external action. The system is more useful when it can distinguish 'I cannot infer this fact', 'I can prepare this action', and 'I am authorized to execute this action'.
NIST's AI Risk Management Framework treats trustworthy AI as a lifecycle risk-management problem rather than a one-time model property. My practical interpretation for agentic products is to make evidence, uncertainty and authority first-class data structures. That gives the product something concrete to test when the model is persuasive but the evidence is weak.
Practical checklist
What I carry into the next system.
- Keep UNKNOWN distinct from FALSE; missing evidence should not become a negative fact.
- Bind material generated claims to explicit provenance before generation, not as a cosmetic citation step afterward.
- Require verified conflicts for hard rejection and let uncertainty change confidence or workflow instead.
- Model preparation, assisted interaction and external submission as different authority levels.
- Treat ambiguous side effects as an explicit state and keep learning loops downstream of deterministic truth controls.
Evidence & references