Attested Computation#

Attested Computation is an advanced concept template. Most users do not need it.

Use it only when you must document:

1. a repeatable calculation;
2. the runtime that performs it;
3. its input parameters;
4. the evidence a run should return;
5. an optional checker or attester.

Creating or opening this concept does not run the calculation.

Simple meaning#

An Attested Computation file is a contract written in Markdown.

It can say:

• “Run this approved calculation.”
• “Use these inputs.”
• “Return these receipt fields.”
• “This separate resource may check the receipt.”

DevDesk validates the written structure. It does not claim that the computation ran or passed.

Create one from the app#

1. Open Developer tools > Structure and OKF.
2. Select Create concept.
3. Set Template to Attested computation.
4. Enter a Title.
5. Review the suggested path under computations/.
6. Add a one-line description.
7. Keep Status as draft.
8. Enter a valid Generated by actor.
9. Enter Runtime, for example python, postgres, or bigquery.
10. Add parameters when needed.
11. Choose either an external computation file or the generated inline fenced block.
12. Add executor, receipt, and attester resources only when they really exist.
13. Select Create.

The Runtime must not be empty. Each parameter line uses:

name:type:required

or:

name:type:optional

Example:

year:integer:required
segment:string:optional

Inline computation#

Leave Computation file empty to create one inline fenced computation block:

# Computation

```python
# Add the sanctioned computation here.
```

Replace the placeholder only with reviewed project content.

External computation#

Enter a relative Computation file when the calculation already exists:

computations/monthly-active-customers.sql

When an external path is used, the template does not also create an inline computation block. Use one method, not both.

Executor, receipt, and attester#

• Executor resource: documentation for the approved execution process.
• Receipt fields: evidence expected from a run, such as job_id, executed_sql, or result.
• Attester resource: documentation or code location for a separate checker.

These fields describe resources. DevDesk does not call them.

Example metadata:

type: "Attested Computation"
title: "Monthly active customers"
runtime: "postgres"
parameters:
  - {name: "start_date", type: "date", required: true}
  - {name: "end_date", type: "date", required: true}
computation: "computations/monthly-active-customers.sql"
executor:
  resource: "references/run-monthly-metric.md"
  receipt:
    - "job_id"
    - "executed_sql"
    - "result"
attester:
  resource: "references/check-monthly-metric.md"

Findings you may see#

Structure checks can warn when:

• runtime is empty;
• parameters are not valid mappings;
• a parameter lacks name, type, or required status;
• neither an external computation nor one inline fenced block exists;
• both external and inline computations are supplied;
• executor or attester does not contain a resource;
• executor receipt fields are missing.

These are structure checks. They are not evidence that the calculation is correct.

Record a real verification#

Only after the appropriate person or process checks the actual result:

1. Return to Structure and OKF.
2. Select Record verification.
3. Select the computation concept.
4. Enter the real actor.
5. Review the plan.
6. Apply it.

The verification event records the stated review. DevDesk still does not run the computation or attester.

Safety rules#

• Never paste credentials into the Markdown contract.
• Never treat a code block as permission to execute code.
• Review computation paths before sharing the workspace.
• Keep receipts and sensitive result data in an appropriate protected system.
• Do not mark a concept stable or verified merely to clear a dashboard count.