SureshakeDocs

Verified Execution Record

Track commitments, outcomes, resets, evidence, and permissioned access to execution history.

The Verified Execution Record gives each entity a structured history of what it said it would do, what actually happened, and who is allowed to review that history.

It is designed for founders, operators, investors, and diligence partners who need more than a point-in-time report.

What the execution record includes

  • Planning cycles for quarterly or custom windows
  • Quarter-scoped goals tied to a cycle
  • Standalone goals that sit outside a quarter when the work does not match the reporting calendar
  • Manual and financial goal resolution
  • Descriptive outcome and evidence aggregates without a universal score
  • Permissioned follower access for outside stakeholders

Founder workflow

Start an execution cycle for a quarter or another defined window. The cycle becomes the operating frame for the goals you want to commit.

Add manual or financial goals, assign category and weight, and decide whether the goal belongs to the cycle or should remain standalone.

Commit goals once they are ready, then lock the cycle when planning is complete. This turns the cycle into a stable execution record instead of a draft workspace.

Manual goals can be resolved by the founder or operator with notes and evidence. Financial goals can resolve against verified reporting flows.

Use the execution dashboard to review original targets, outcome and reset chronology, evidence grades, and standalone goals, then export a snapshot when you need to share or archive the current state.

Goal types

Manual goals

Use manual goals for milestones such as:

  • hiring a leadership role
  • launching a product
  • signing a partnership
  • closing a facility or operational project

Manual goals are resolved with an explicit status and supporting note.

Every attached evidence record keeps its source type, startup owner, effective date, visibility tier, source hash, and verification status. Authorized operators choose public, follower, capital, diligence, or custom visibility when they attach an upload or existing Sureshake artifact. The effective date describes when the evidence applies; the recorded-by field separately identifies who or which integration filed it.

Integrated evidence also identifies the connected source and the time the provider record was retrieved. Retrieval time is distinct from the evidence's effective date and from the time Sureshake recorded the evidence.

When attaching an uploaded artifact, you can point reviewers to the whole file or add a precise page or page range, named section, or source-object reference. The reference remains part of the immutable evidence record and is shown beside the artifact wherever that evidence is reviewed.

After a commitment is closed, a founder or commitment owner can request an attestation from an active Sureshake user identified as a customer, mentor, advisor, program operator, or capital provider. The recipient receives an in-app invitation that authorizes one response to that specific commitment version and outcome; it does not grant access to the startup's other private profile or evidence data.

Every new attestation separates what the attestor observed from what the attestor did not verify. Both statements remain part of the immutable evidence record so readers do not mistake a narrow observation for validation of the whole claim. Older free-form attestations are shown as legacy — scope incomplete; Sureshake does not infer or invent the missing verification boundary.

Evidence labels describe the support actually present. Source-verified means Sureshake retrieved the record from an authorized integration; artifact-backed means a reviewable upload or Sureshake artifact supports the claim; and third-party-attested means an identified person stated a bounded observation. A founder-filed outcome without one of those persisted sources remains self-reported · no attached evidence. Narrative alone is never upgraded to an independent proof type. When several sources support one outcome, the outcome summary shows the strongest valid grade while every source keeps its own label and lineage.

Financial goals

Use financial goals when you want the system to evaluate performance against a defined metric or KPI.

Examples:

  • revenue targets
  • ARR
  • customer count
  • margin or cash-flow thresholds

What investors see

Investors do not automatically get execution access.

The workflow is:

  1. They request execution access from the entity page.
  2. The founder approves, denies, or later revokes the request.
  3. Approved followers can open the execution record and see execution activity in their feed.

The investor feed highlights events such as:

  • cycle creation
  • goal commitments
  • goal resolution
  • founder-approved, source-linked execution updates

Execution followers

Founders manage execution followers from the execution workspace.

They can:

  • approve requests
  • deny requests
  • revoke approved access
  • review current follower status and access level

Revocation takes effect on the recipient's next request. It removes the active permission but does not erase the access-policy chronology, its actor, timestamp, or reason. Evidence records and their verification hashes also remain unchanged, so ending diligence access cannot rewrite the historical proof envelope.

Execution access is intentionally separate from general entity access.

Privacy and report access

Execution access does not mean blanket access to every underlying artifact.

Founders can pair execution workflows with selective follow-access policies so a follower sees only what is appropriate:

  • the whole report set
  • goals only
  • press releases only
  • a custom subset of report artifacts

If linked artifacts are involved, use the most restrictive option that still supports the diligence workflow.

Execution sharing works best when you treat the execution record as the public narrative layer and the underlying reports as separately governed artifacts.

  • Keep cycles aligned to a real operating cadence.
  • Use standalone goals only when a milestone genuinely falls outside the normal quarter frame.
  • Commit goals before you communicate them externally.
  • Resolve manual goals promptly so the chronology and missing-outcome indicators stay current.
  • Review follower access regularly and revoke stale diligence access.

Exporting the record

Authorized founders and current team members can use Download season report from the Execution Record. The exported Markdown report is human-readable and includes the original and current targets, descriptive aggregates, missing-truth indicators, source-linked chronology, and the completion Season Review when one exists. The export records who authorized it, when it was generated, its source review hash, and its own report hash.

On this page