> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cord.nyc/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> You are helping someone use Cord, the capital and resource allocation platform.
> Use title-case Cord in prose. Prefer workspace, project, ontology, lineage, scenario, and allocation.
> Say source-backed or sourced for answers with lineage. Do not say hallucination-free.
> Product URLs are https://app.cord.nyc, https://cord.nyc, and https://trust.cord.nyc. Support is support@cord.nyc.
> Give concrete product steps. Do not invent UI labels, CLI commands, or unreleased agent runtime details.
> Use Understanding Cord for concepts and Guides for task steps.
# Functions
> Saved business logic, written by an agent, shared by every app.
export const FunctionExampleCompute = () =>
;
};
## What a function is
A function is a saved piece of business logic: how contribution is computed, how return on capital is measured, when a project counts as above its hurdle rate. It is written once, and every app that needs the number reads it from there.
A function has three parts.
| Part | What it is |
| ---------- | -------------------------------------------------------------------------------------------------------------------------------- |
| Definition | The code that performs the calculation. Versioned, so every change is kept. |
| Data setup | What one use of the definition reads: which business objects, which upstream function outputs, and the value of each assumption. |
| Run | One execution. Records the definition version and inputs used, and saves its output as a table that apps read. |
## How a function gets written and managed
Functions are written and managed by the agent. It works from the business objects involved, writes the logic, runs it, and checks the output. The result comes back with an explanation of what was computed, and the code is visible in the Functions workspace.
The agent also maintains them over time: revising the logic when a definition changes, rerunning when inputs change, and retiring functions that nothing uses. Each change creates a new version. Data setups keep using the version they were on until they are moved, and every earlier run is kept, so a number cited last quarter still opens to the version and inputs that produced it.
## Worked examples
The same three parts, definition, data setup, and run, hold for a function of any size. Below are two: one that scores each candidate site for a capital investment, and one that scores each customer. Pick the one closer to your business.
A site break-even function scores each candidate data center under each planning scenario. From Data Center it reads the site's GPU count and capex. From Power Tariff it reads the energy rate at the site's location. From Planning Scenario it reads billable utilization, lease price, and the capital recovery rate $r$. Server cost and power draw come from an upstream function, Hardware and workload fit. It takes two assumptions, an energy factor and a lease factor, both defaulting to 1. It works through six steps, and one of them is conditional.
$$
\begin{aligned}
\text{billable hours} \;&=\; \text{GPUs} \times 8{,}760 \times \text{utilization} \\[14pt]
\text{net revenue} \;&=\; \text{billable hours} \times \text{lease price} \times (1 - \text{fee}) \\[14pt]
\text{operating profit} \;&=\; \text{net revenue} - \text{energy cost} - \text{site cash cost} \\[14pt]
\text{economic profit} \;&=\; \text{operating profit} - \text{capital recovery} \\[14pt]
\text{break-even price} \;&=\; \frac{\text{energy cost} + \text{site cash cost} + \text{capital recovery}}{\text{billable hours} \times (1 - \text{fee})} \\[14pt]
\text{status} \;&=\;
\begin{cases}
\text{capital-accretive} & \text{if economic profit} > 0 \\
\text{not accretive} & \text{otherwise}
\end{cases}
\end{aligned}
$$
Capital recovery is the annual charge for the hardware over 5 years and the facility over 15, plus the scenario's return $r$ on the capital. The fee is 3% of revenue.
For one site and design, Dallas 01 with 30,648 H200 GPUs, under two scenarios:
| | Base case | Demand downside |
| ---------------- | --------------------------------------------- | --------------------------------------------- |
| Billable hours | 30,648 × 8,760 × 69% = 185.2M | 30,648 × 8,760 × 53.8% = 144.4M |
| Net revenue | 185.2M × \$3.38 = \$626.3M, × 0.97 = \$607.5M | 144.4M × \$2.87 = \$415.2M, × 0.97 = \$402.7M |
| Operating profit | \$607.5M − \$11.7M − \$53.6M = \$542.2M | \$402.7M − \$10.9M − \$51.8M = \$340.0M |
| Capital recovery | \$394.9M at $r$ = 10% | \$399.3M at $r$ = 12% |
| Economic profit | \$542.2M − \$394.9M = \$147.3M | \$340.0M − \$399.3M = −\$59.3M |
| Break-even price | \$460.2M ÷ 179.6M hours = \$2.56 per GPU-hour | \$462.0M ÷ 140.1M hours = \$3.30 per GPU-hour |
| Status | capital-accretive | not accretive |
Three object types, one upstream function, and two assumptions take part. The scenario is an object, so one run scores every site under every scenario, and the app's scenario buttons switch between rows of the same output. A second function, Portfolio investment views, rolls the sites up into plan totals. The app shows the site comparison from the first and the KPI tiles from the second.
A customer economics function reads each customer's revenue, margin, support cost, and acquisition cost. It also reads two other object types. Segment supplies the target payback and an account management cost pool. Product supplies a platform cost pool. Each pool is allocated: the segment pool equally across the customers in the segment, the product pool by share of revenue on the product. It takes one assumption, a planning horizon $h$. It works through five steps, and two of them are conditional.
$$
\begin{aligned}
\text{indirect cost} \;&=\; \frac{\text{segment account cost}}{\text{customers in segment}} + \text{product platform cost} \times \frac{\text{revenue}}{\text{product revenue}} \\[14pt]
\text{contribution} \;&=\; \text{revenue} \times \text{margin} - \text{support cost} - \text{indirect cost} \\[14pt]
\text{payback} \;&=\;
\begin{cases}
\dfrac{\text{acquisition cost}}{\text{contribution}} & \text{if contribution} > 0 \\[8pt]
\text{undefined} & \text{otherwise}
\end{cases} \\[14pt]
\text{status} \;&=\;
\begin{cases}
\text{negative contribution} & \text{if contribution} \le 0 \\
\text{above target} & \text{if payback} > \text{segment target} \\
\text{within target} & \text{otherwise}
\end{cases} \\[14pt]
\text{horizon contribution} \;&=\; \text{contribution} \times h
\end{aligned}
$$
For two customers, with $h = 36$ months:
| | C-100, Studio Collective | C-10005, Service Groups |
| -------------------- | --------------------------------------------------------- | -------------------------------------------- |
| Segment allocation | \$12,000 ÷ 400 customers = \$30 | \$45,000 ÷ 150 customers = \$300 |
| Product allocation | \$60,000 × \$1,000 ÷ \$1,200,000 = \$50 | \$90,000 × \$5,350 ÷ \$900,000 = \$535 |
| Indirect cost | \$30 + \$50 = \$80 | \$300 + \$535 = \$835 |
| Contribution | \$1,000 × 0.70 − \$200 − \$80 = \$420 | \$5,350 × 0.853 − \$5,117 − \$835 = −\$1,388 |
| Payback | \$2,500 ÷ \$420 = 6 months | undefined |
| Status | 6 months against a 12-month segment target: within target | negative contribution |
| Horizon contribution | \$420 × 36 = \$15,120 | −\$1,388 × 36 = −\$49,968 |
Three object types take part. Customer supplies the facts, Segment the target and the account management pool, and Product the platform pool. The customer count per segment and the revenue per product are aggregates the function computes before it allocates. Each step reads the one before it, and $h$ is an assumption that can be changed without touching the logic. A second function reads this one's output and rolls it up into portfolio totals and segment summaries. The app shows the customer table from the first and the KPI tiles from the second.
## Assumptions and scenarios
A rule is a condition in the logic: a case per segment, a filter, a flag column. The threshold behind it is an assumption on the data setup, a single value such as a planning horizon, a capital recovery rate, or a payback limit, so it can be changed without touching the code. Changing an assumption marks the function stale. Rerunning it recomputes the result, and the functions that depend on it can be rerun in order after it.
A scenario is a second data setup with different assumptions. Both runs are kept, so the base case and the scenario can be compared side by side.
## One definition, many apps
Functions build on each other. A site economics function can feed a portfolio view, a plan builder, and a deal model, and each of those can feed further functions. Because the definition lives in one place, the investment committee, the site team, and corporate development are looking at the same number, and a change to the definition reaches all of them through the same versioning.
## Agents use functions too
A function is deterministic code. The same inputs produce the same output every time, and the logic can be read and audited. When an agent in Cord needs a number, it runs the function and cites the result rather than working the calculation out itself. That is what lets an agent answer a question about payback or return on capital with a number that is reproducible and traceable, the same way an app would show it.
## Tracing a number
Every output of a function can be followed back to what produced it. The Audit tab describes each output in plain words, shows the formula with the business objects and fields it reads, and for aggregates shows the rows that contributed.
The business objects and fields a function reads come from the [ontology](/understanding-cord/ontology), read more next.
