The build output

farthershore build loads the business/ program, validates the declaration graph, and writes a canonical Manifest IR envelope.

farthershore build
farthershore build --format json
farthershore build --entry business/ --out business-build.json

Normal folder discovery is preferred. Use --entry only when deliberately building another folder or file.

What is in the artifact#

Manifest IR contains the normalized business contract: logical backends, routes and policies, meter attachments, plans, grants, limits, resources, frontend integrations, and permission-group declarations. The business-wide RBAC enablement flag is operating state. The artifact also carries SDK and IR versions plus a deterministic hash.

It does not contain arbitrary repository code, concrete backend origins, decrypted secrets, customer rows, active deployment state, or presentation metadata.

Authenticity and validation#

Only an authentic fs.business() result from the loaded SDK instance compiles. Raw objects and schema-shaped JSON cannot impersonate a built program.

The build executes TypeScript through the SDK loader; it is not a TypeScript type checker. Run the business repository's separate typecheck command before the build (for example, its configured tsc --noEmit script). Neither gate replaces the other: a type-correct program can still violate runtime invariants, and an ill-typed program can execute successfully after TypeScript is transpiled.

The build validates runtime invariants: duplicate declarations, dangling refs, unmatched metering selectors, invalid plan combinations, unattached limited dimensions, conflicting route methods, and secret-bearing contract values.

Determinism gate#

The loader compiles the program in isolated workers and compares hashes. An observed difference is rejected. Matching hashes are not proof of source purity: an environment variable, clock value, file, or network response could happen to return the same value in both runs. Do not depend on those external inputs in contract declarations, even if a particular build passes.

Computed constants and helper functions are fine when their result is purely a function of source-controlled inputs.

Local build vs accepted contract#

A successful local build proves only that your checkout compiles. Push the source and wait for the repository validation/apply check. Core accepts the IR, computes the semantic release impact, and applies environment-specific state.

git push
farthershore apply-timeline list <business>
farthershore business contract <business>

If the pushed apply fails, the previous accepted contract remains authoritative. Fix the source and push another commit rather than editing generated IR.

Do not commit build artifacts unless the business repository's own instructions explicitly require them. The TypeScript program is the reviewable source.