Zoikorum™
MILESTONES & DELIVERABLES

Make delivery stages clear — from work in progress to accepted evidence.

Structure each delivery stage around the current scope, expected evidence, review authority and acceptance record, while keeping payment and governance state connected but distinct.

Version-aware
Evidence-linked
Authority-aware
Source-connected
Make delivery stages clear
EVIDENCE · SUBMISSION V2
Deliverable A
v2
Supporting note
v2
Reference link
v2
WHAT MILESTONES MAKE CLEAR

Clarity and traceability — not certainty of outcome.

Clear delivery stage

Clear delivery stage

Know what this stage expects and which work definition governs.

Milestone card + linked SOW badge
Evidence attached to the stage

Evidence attached to the stage

Submissions and supporting evidence stay connected to the milestone under review.

Evidence stack with version metadata
Explicit decision authority

Explicit decision authority

Acceptance is made by the permitted actor, against the current version.

Authority chip + review panel
Durable history

Durable history

Changes, submissions and decisions remain traceable in the engagement record.

Timeline with actor + time + version
MILESTONE LIFECYCLE

Six stages, three perspectives.

BuyerProfessionalPlatform
1
Define
2
Work
3
Submit
4
Review
5
Decide
6
Continue
Submit Stage
STAGE 03

Submit

BUYER

RECEIVE A REVIEW-READY SUBMISSION.

MILESTONE ANATOMY

One milestone, annotated.

Select a region of the example card to see what it holds and where its boundary sits.

MS-02 · Milestone 2 · Deliverable review
Submitted for reviewv3EXAMPLE
01Header
MS-02 · Deliverable review · seq 2 · Submitted · v3
02Governing context
Engagement · SOW v4 · Deliverable A
03Delivery definition
Objective · expected deliverable · evidence expectations
04Timing
[Target window, if configured]
05Professional actor
Example Advisory LLC · delivery lead
06Acceptance context
Criteria from SOW v4 · Finance Lead
07Submission
v2 · 3 items · [submitted by / time]
08Decision
Pending
09Payment relationship
Linked · open payment record
10History
Versions · submissions · decisions · events
Milestone anatomy review
EVIDENCE & SUBMISSION

Submit once. Keep it traceable.

Try it: add evidence, simulate a definition change, then submit an immutable review target.

Submit for review · MS-02 v3
MS-02 · Milestone 2 · Deliverable review · v3
Deliverable A - draftLinked to Deliverable A
Allowed types come from configuration — no universal list.
Deliverable A · SOW v4
Draft saved · not visible as submitted
Evidence submission workspace
Drafts never appear as submitted to the buyer.
Later evidence creates a new submission version — what was reviewed is never silently replaced.
Upload or security failures show explicit partial states — no false “submitted.”
REVIEW & ACCEPTANCE

The right person, the right version.

Decide on the example. A stale review target disables acceptance.

Review · MS-02 v3 · submission v2 · SOW v4
EVIDENCE SUMMARY

3 items · descriptions, timestamps and visibility shown for each.

ACCEPTANCE CONTEXT

Criteria reference from SOW v4 · no unresolved warnings. No pass score is invented.

AUTHORITY

Finance Lead · acceptance authority for MS-02 under the engagement configuration.

PRE-ACTION CHECK

Version, authority, hold/dispute and policy state revalidated before recording.

Review and acceptance workspace
ONLY RELEVANT ACTIONS

Accept and Request changes — other outcomes appear only when configured.

CHANGE, REBASE & VERSIONING

Stale state is shown, never hidden.

01
Changed before work begins
02
Changed while in progress
03
Changed while submitted for review
04
Accepted milestone later amended
05
SOW version superseded
Changed while submitted for review
SCENARIO 03

Changed while submitted for review

The review context is marked stale and acceptance against the obsolete target is disabled until the authoritative workflow resolves the change.

COMPARE GROUPS
ObjectiveDeliverablesEvidence expectationsTimingResponsibilitiesAcceptance contextCommercial references

Added / Changed / Removed are labelled in text. A compare view is informative — it never approves the change itself.

PAYMENT RELATIONSHIP

Connected, never conflated.

Explore Payment Protection
Submitted
≠
Funded / released
Submission never means funded or released.
Accepted
≠
Release
Acceptance may be one input where configured; it is not the release itself.
Changes requested
≠
Financial hold
No automatic hold unless the authoritative payment workflow does so.
Blocked / disputed
≠
Payment outcome
Source-linked hold/dispute context — never an invented outcome.
Cancelled
≠
Refund
No refund is inferred; route to Refund & Cancellation.
Payment relationship context
REQUIRED COPY

Milestone acceptance and payment status are separate. Where supported, payment workflows can use milestone and approval state as inputs. The current financial state is shown in the authoritative payment record.

FOR BUYERS & PROFESSIONALS

Clear stages, on both sides.

For buyers

For buyers

See what each stage expects and which SOW version governs.
Review inspectable evidence, not just a file count.
Decide with explicit authority, against the right version.
For professionals & firms

For professionals & firms

Know the expectation before work starts.
Submit evidence that stays traceable.
Receive explicit decisions and next actions.
User illustration
User illustration
User illustration
User illustration
Buyers, professionals and firms · Illustrative photography
Define the stage
Define the stage
Submit the evidence
Submit the evidence
Record the decision
Record the decision
QUESTIONS

Milestones, answered.

Milestones answered
Contact Sales
Get started with milestones
GET STARTED

Clear stages. Accepted evidence.

Find expertise, join as a professional, or govern milestones across your organization.

Milestones provide clarity and traceability, not certainty of outcome. Acceptance is not payment, legal completion or a dispute waiver; availability depends on engagement configuration.