PHOROS TECHNICAL PLATFORM

A Technical Platform for Forward-Deployed Work.

Compose interfaces, typed business records, server-side operations, agent reaches, human approvals, previews, and stable publication inside one governed application model.

Inspect the Execution Model See the FDE Workflow
ComposeInterface and data
ExecuteOperations and reaches
PublishReviewed stable source
THE DELIVERY SYSTEM

One Application Model Instead of a Stack of Handoffs

Forward-deployed work fails when the interface, business data, automation, agent context, and publication trail live in separate tools with separate owners.

FRAGMENTED DELIVERY
  • Website or portal builder
  • Separate CMS and database
  • Automation service
  • Agent framework and memory
  • Manual deploy and rollback story
  • Evidence reconstructed after the fact
Every boundary becomes another place for context to disappear.
PHOROS APPLICATION

One governed work record.

Pages, source divisions, typed content, processors, agent reaches, surfaces, draft proof, and stable publication share the same tenant and execution context.

NATIVE PRIMITIVES

The Small Set That Carries the Whole Job

Each primitive has one technical responsibility. Their composition is the platform.

01

Webapp

The tenant boundary for domains, globals, pages, processors, content models, people, and publication state.

02

Page and division

A page composes addressable divisions. Each division owns markup, scoped presentation, behavior, metadata, and source state.

03

Content type

A typed business record with fields, validation, tenant ownership, and a projection into one or more page surfaces.

04

Processor

A server-side operation that reads and changes authorized business state without moving authority into the browser.

05

Agent reach

An explicit system or action an agent may use, bounded by the organization, workflow, and human approval design.

06

Surface and receipt

Web, desktop, and mobile views share the work record; observable outcomes preserve who did what and what happened.

RUNTIME BOUNDARIES

Authority Lives With the Layer That Can Enforce It

The browser renders and requests. The server authenticates, scopes, computes, changes records, and returns the outcome. Publication remains a separate reviewed action.

IDENTITY AND DATA
  • Builder identity and application end-user identity are distinct realms
  • Tenant ownership is resolved on the server
  • Content and processor operations remain organization-scoped
  • Private documents are served through authorized access
  • Business amounts and consequential calculations are server-owned
SOURCE AND EXECUTION
  • Division source is addressable as markup, scoped CSS, and behavior
  • Draft and stable are explicit source layers
  • Preview does not imply publication
  • Processors carry server-capable effects
  • Agent actions remain observable and reviewable
CAPABILITY BOUNDARY

If an effect requires a capability the browser does not own, the effect belongs in a server-side processor or an authorized platform reach, not a client-side workaround.

EXECUTION MODEL

From Source Unit to Stable Business Surface

The architecture is record-native: source, data, operations, permissions, and publication are independently addressable but share one application authority.

WEBAPPTenant, domain, globals, people, publication
INTERFACE

Pages compose divisions

Each division carries HTML, scoped CSS, JavaScript, metadata, parentage, position, and draft/stable source.

DATA

Content types carry records

Fields define the business shape. Records remain tenant-owned and can project into listing and detail surfaces.

OPERATIONS

Processors own server effects

A processor receives bounded inputs, acts against authorized systems and records, and returns an explicit outcome.

AGENT

Reaches define available work

An agent can use only the systems and actions made reachable for the job, under the workflow's authority design.

CONCEPTUAL DIVISION RECORD
{
  "page": "refund-review",
  "division": "decision-panel",
  "source": ["HTML", "scoped CSS", "JavaScript"],
  "contentType": "refund-request",
  "processor": "review-refund",
  "sourceLayer": "draft",
  "publication": "review required"
}
PUBLICATION LIFECYCLE
  1. Author draftChange one addressable source unit.
  2. Render real contextUse the composed page, globals, data, and permissions.
  3. Verify both shapesExercise success, refusal, empty, and recovery states.
  4. Review evidenceInspect tests, chain, rendered proof, and business acceptance.
  5. Commit stablePublish reviewed source with a durable commit identity.
WebDesktopAndroidiOS

The interface can change by surface. The tenant, business record, operation, agent context, and receipt remain the same authority.

RUNTIME CONTRACTS

Know Which Layer Owns Each Kind of Truth

Technical delivery stays tractable when shape, effect, authority, and publication do not collapse into one script.

Client renderer
Composes globals and the selected page from addressable source divisions. It owns interaction and presentation, not privileged effects.
Content model
Defines typed business fields and tenant-owned records independently from any one screen.
Processor runtime
Executes server-capable work with verified caller and organization scope, then returns an explicit result.
Agent reach
Exposes only the systems and actions the job is authorized to use. Human approvals remain part of the workflow.
Publication boundary
Keeps working source in draft until the composed behavior and evidence are reviewed, then writes one stable commit identity.
Proof surface
Pairs record tests and chain checks with a real rendered press, failure-path evidence, and the business acceptance measure.

This page is running on the model it describes.

Its global header, page tree, source divisions, scoped styles, behavior, metadata, preview, and stable publication are all Phoros application records.

The architecture is not a diagram pasted over a different stack. It is the live delivery surface.

OWNERSHIP MODEL

Three Authorities, Kept Deliberately Separate

YOU OWN

The implementation

Workflow design, page source, content shape, processor behavior, agent instructions, evaluations, and the review standard.

PHOROS OWNS

The managed platform

Tenant runtime, application composition, identity boundaries, hosting, domains, files, source layers, and publication mechanics.

THE ORGANIZATION OWNS

The business authority

Its data, decisions, approvals, relationships, operating rules, success measure, and the right to stop or change the workflow.

TECHNICAL QUESTIONS

How the Platform Behaves

What is the smallest deployable source unit?

A division. It is an addressable part of a page with its own markup, scoped CSS, JavaScript, metadata, position, lineage, draft source, stable source, and version history.

Where does server-side behavior live?

In processors and authorized platform reaches. The browser requests an operation and renders the result; it does not become the authority for tenant scope, identity, payments, private files, or consequential record changes.

How are business records separated from pages?

Content types define fields and records independently from presentation. A listing or detail page can project that content without making the screen the database schema.

What is the draft and stable boundary?

Draft is the working source rendered for review. Stable is the public source written only after the composed page and relevant behavior are verified. A durable commit identity records that publication.

How do agents fit the runtime?

An agent operates through explicit reaches and workflow instructions. It can prepare or act only within the connected systems and authority boundaries, while the application keeps the human approvals and outcomes visible.

Bring a Workflow, Not a Blank Canvas.

Start with the process, records, decisions, systems, and success measure. Then use the platform primitives to compose the smallest governed deployment that can prove the result.

Run the FDE Audit

Addressable source · Server-owned effects · Draft proof before stable publication