Skip to main content
Feature proof

A feature is not proven because a screen exists.

Use this protocol during evaluation and onboarding to follow one bounded workflow from source evidence through policy, authority, provider acknowledgement, failure handling, and export. It prevents a prepared or queued action from being presented as completed.
Protocol 2026-07-22.v1
Completing it is not a legal, security, provider, compliance, or outcome certification.
Aptoria
Status ladder
Visible in product
Prepared for review
Internally authorized
Provider acknowledged
Pilot evidence complete
Acceptance packet
Name the bounded workflow
Show policy and authority
Prove the external handoff
Run the same five checks for every workflow
Protocol 2026-07-22.v1
1
Name the bounded workflow
Trigger, property or portfolio scope, source record, and accountable owner.
2
Show policy and authority
Effective policy version, named authority, limits, and the non-delegable human boundary.
3
Prove the external handoff
Provider state and receipt when an external payment, message, signature, listing, calendar, or vendor action is expected.
4
Force the exception path
A missing fact, failed provider, or exceeded limit that visibly stops and routes to a named owner.
5
Verify export and exit
A usable export of the workflow record, evidence references, unresolved items, and ownership.
Feature proof
Visible in product
Protocol
2026-07-22.v1
Acceptance packet
5
Status ladder
5
Visible in product
Prepared for review
Internally authorized
Provider acknowledged
Pilot evidence complete
What this protocol deliberately does not prove
It does not prove legal compliance, security certification, provider settlement, message receipt by a person, completed repair quality, accounting correctness, or a production service commitment. Those conclusions require their own source evidence and accountable review.
Five states that must not collapse into “done”
1. Visible in product
2. Prepared for review
3. Internally authorized
4. Provider acknowledged
5. Pilot evidence complete
Completing it is not a legal, security, provider, compliance, or outcome certification.
Status ladder

Five states that must not collapse into “done”

1. Visible in product
A route, control, demo state, or catalogue entry exists. This does not prove that the workflow is configured or released.
2. Prepared for review
The workflow has a named scope, accountable owner, and source evidence. Preparation is not authorization or execution.
3. Internally authorized
The effective policy, authority evidence, limits, and human boundary are present. An external action may still be pending or unavailable.
4. Provider acknowledged
The configured provider returned a linked acknowledgement for the external step. This is not proof of every downstream outcome.
5. Pilot evidence complete
The bounded protocol also passed an exception test and export check. Production release remains a separate accountable decision.
Acceptance packet

Run the same five checks for every workflow

1
Name the bounded workflow
Trigger, property or portfolio scope, source record, and accountable owner.
2
Show policy and authority
Effective policy version, named authority, limits, and the non-delegable human boundary.
3
Prove the external handoff
Provider state and receipt when an external payment, message, signature, listing, calendar, or vendor action is expected.
4
Force the exception path
A missing fact, failed provider, or exceeded limit that visibly stops and routes to a named owner.
5
Verify export and exit
A usable export of the workflow record, evidence references, unresolved items, and ownership.
What this protocol deliberately does not prove
It does not prove legal compliance, security certification, provider settlement, message receipt by a person, completed repair quality, accounting correctness, or a production service commitment. Those conclusions require their own source evidence and accountable review.