The proposed action
A machine-readable action, target, segment, threshold or intervention appropriate to the business decision.
Decision API
Graphite Note can deliver model outputs as machine-readable decision objects so another application can consume a recommendation, expected impact, confidence and supporting evidence without forcing users into a separate analytics screen.
Machine-readable output
The exact contract depends on the use case and integration. A decision object can carry the fields required by the receiving system, including decision context, recommendation, expected impact, confidence, evidence and governance state.
The example shown here is illustrative, not a fixed public API contract.
{
"decision": "reduce_discount",
"segment": "high_value_repeat_customers",
"recommended_change": "-5%",
"expected_margin_impact": "+180000 EUR",
"confidence": 0.88,
"evidence": ["causal_effect", "uplift_test"],
"review_required": true
}Integration pattern
The receiving system can be an ERP, CRM, BI product, workflow platform, vertical SaaS product or AI agent.
What can be returned
A machine-readable action, target, segment, threshold or intervention appropriate to the business decision.
An estimated business effect, uncertainty or confidence value when the underlying method supports it.
References to model outputs, causal evidence, constraints or other decision context required for audit and review.
Policy-bound execution
For agentic or automated workflows, the useful contract is not just an action. It is an action that has been checked against the relevant business policy and can state what the receiving system is allowed to do next.
Candidate actions can be screened against product, customer, commercial and operational rules before recommendation.
The object can distinguish actions that are safe to execute automatically from those that require review or escalation.
Keep the recommendation, expected impact, evidence, governance state and eventual outcome together so the decision can be reviewed later.
Outcome feedback loop
A governed decision system can keep the recommendation and the eventual result connected so teams can review whether the expected effect happened, where performance drifted and which decision rules deserve another look.
Keep the action taken, approval state, target and execution context tied to the original decision object.
Attach the realised business outcome when it becomes available and compare it with the expected effect and uncertainty.
Surface systematic gaps, changing conditions or weak decision rules for model, policy or workflow review rather than assuming every recommendation remains valid forever.
Direct answers
No. It is designed to let an existing product keep its own interface and workflow while consuming the decision layer programmatically.
Yes. A workflow can keep approval with the responsible user and use the API to provide the recommendation, expected impact and evidence needed for that review.
Yes, where the integration is appropriate. The agent can use a governed decision object as a structured tool output instead of inventing an action from free-form text alone.
The integration can include policy, eligibility and operating constraints before a recommendation is returned, plus a governance state that tells the receiving workflow whether the action may proceed, needs approval or should be escalated.
Yes. The workflow can attach the action taken and the eventual business outcome to the original decision object so expected-versus-actual performance can be reviewed later. That supports audit, monitoring and improvement without treating every recommendation as permanently correct.
We can scope the decision object and integration around one high-value use case.