Architecture

Harness helps a model build the company model, and it runs actions on that model. Both go through one kernel, the core that holds the records and enforces the rules, and both end at an owner's approval.

#Two jobs, one kernel

The kernel has five parts: contract (the rulebook), identity (one object across systems), ledger (every fact with its three times), rules (admit, refuse or ask) and actions (proposal, approval, release, receipt, outcome).

#Layers

#External business systems

The ERP, CRM, ledger and spreadsheets stay authoritative for their own records. Harness becomes the system of record for what the business knows about them, from where, and since when.

#Connector and observation layers

Evidence enters as observations, pushed by a source holding a scoped source token or pulled on a schedule. The pull runtime holds a lease per run, validates a complete snapshot in memory, and publishes facts and links atomically with a run evidence manifest.

#Application services

One operation set is the only way in. The CLI, the HTTP service and the agent tools all call ApplicationServices.invoke with a host-built caller, an operation, arguments, a contract version and a request ID.

ApplicationServices.invoke(Caller(business, actor, view="model"), "list_objects", args, version, request_id)

#Surfaces

The terminal is an authenticated loopback client of the service. The web workspace is the owner's approval surface today. The Python SDK is an HTTP client using a scoped API token, with no approval or release method. The builder MCP bridge is a local stdio client of the same service; a hosted MCP endpoint is planned.

#Not built yet