Schedule, cost, and risk.
Reconciled by AI, governed by your team.

Our agents and yours reach the same engines, over MCP or from Teams, Outlook and other channels. Every confirmation is authenticated and attributed to a named person.

orchestration.lognos: cascade running
Field progress
capturing progress ✓_
Update queue
triaging updates ✓_
Planner
held for planner ✓_
Schedule SoR & engine
writing schedule ✓_
Actuals in
ingesting actuals ✓_
Waterfall
forecasting ✓_
Cost signs off
awaiting sign-off ✓_
Risk engine
simulating composite ✓_
Report
compiling report ✓_
PM confirms
awaiting confirm ✓_
live update propagating a named person confirms
01Field progressSite capture enters the cascade. Cost actuals can start the same loop from the other side.
02Schedule SoR & engineQueued updates pass a guardrail. Direct and mechanical fixes write; second-order or unclear changes are held for a planner.
03Waterfall forecastA deterministic commitment + accrual forecast, signed off by the cost controller. Not the risk engine.
04Risk engineA separate computation: cost × schedule × the risk register, producing a risk-adjusted forecast.
05ReportThe PM confirms. That confirmation is the decision. Pending tasks start the next cycle.
Telegram Outlook Microsoft Teams SharePoint ChatGPT Claude Gemini MCP Supabase

What it is

Project controls, done continuously

Three teams maintain three versions of the truth, and they only agree on the day the report goes out. That isn't carelessness. It's arithmetic. A validated, reconciled forecast used to take days of expert work, so it happened monthly, and everyone agreed to call that current. That constraint is gone. Lognos reconciles schedule, cost, and risk against each other continuously, so the picture a decision gets made against is never more than an update old.

LIVE

One picture, not three

Schedule, cost, and risk aren't separate products wired together after the fact. They run as three engines over a single record, reconciling against each other continuously. Most tools in this market do one of the three well and leave the reconciliation between them to you and a spreadsheet.

LIVE

The confirmation is the decision

Nothing writes without prepare → confirm → commit. Not a policy bolted on after the fact. It's the same mechanism that makes the loop worth having.

LIVE

Open at the edges

Integrated inside, open outside. The engines are reachable over MCP by any compatible agent: Claude, ChatGPT, or one your own team builds. You shouldn't have to adopt our interface to get value from our reasoning.

LIVE

Says what it doesn't know

Per-project, per-question capability declaration: available, unavailable, or partial, with a reason. Never a confident wrong answer.

Risk

Risk, triggered from more than one place

Project communications, ingested documents, live world signals, and schedule or cost deltas all land in the same identification step. Matches update the register; new actions open a governed review. The reviewer-commit path is still being hardened. Everything around it is live.

risk-register.lognos: identification running
Communications
reading comms ✓_
Documents
ingesting docs …_
World signals
searching world ✓_
Schedule & cost
reading deltas ✓_
Extract
de-duplicating ✓_
Classify
assigning owners ✓_
Risk register
updating register ✓_
Risk engine
simulating composite ✓_
Risk board
compiling board ✓_
Task to owner
notifying owner ✓_
Proposed
opening proposal ✓_
In review
awaiting review ✓_
Reviewer
commit not live_
live update propagating a named person confirms in progress, not yet enabled
01Four signal sourcesCommunications, documents, world search, and schedule or cost deltas. Documents are built, not yet live on a client register.
02IdentificationExtract, de-duplicate, match the existing register, classify, and assign an owner. Proposals, not silent duplicates.
03Action workflowProposed → in review → final validation. The reviewer commit that advances a task is the gap still being hardened.
04Risk engineThe same engine as the main cascade: cost × schedule × the register. One computation, not a second risk model.
05Board & tasksStatus lands on the risk board; work is surfaced to the owner over the app, Telegram, email, or MCP.

Playbooks

Every loop is a playbook you can read

A workflow isn't a black box inside the agent. It's a declared document: which engines run, in what order, under which guardrail, and exactly where a named human has to confirm before anything commits.

playbooks/cost-reconciliation.xml 
<!-- field + actuals → schedule guardrail → waterfall, then a separate Monte Carlo --><playbook id="cost-reconciliation" version="5">  <trigger on="progress.updated" scope="project" />  <trigger on="actuals.updated" scope="project" />  <step engine="schedule" name="queue">    <guardrail mode="deterministic">      <auto when="direct | mechanical-fix" />      <hold when="second-order | unclear" role="planner" />    </guardrail>  </step>  <step engine="cost" name="waterfall" after="queue">    <method>commitment+accrual</method>    <confirm role="cost-controller" />  </step>  <step engine="risk" name="simulate" after="waterfall">    <montecarlo iterations="10000" inputs="cost × schedule × register" />  </step>  <confirm role="project-manager">    <render template="impact-summary" immutable="true" />    <fingerprint algorithm="sha-256" />  </confirm>  <commit idempotency-key="{{run}}" audit="true" /></playbook>

Governance

The confirmation is the decision.

In most agentic tools, governance is the tax paid for automation, bolted on after the agent already acts. For Lognos the confirmation step and the decision moment are the same event. The loop runs continuously so that when you're asked, you're asked at the moment that matters, with a current picture.

01

Prepare

An immutable draft is rendered: schedule, cost, and risk impact, in full.

02

Confirm

A named person reviews the draft and confirms. This is the decision.

03

Commit

The write lands with a content fingerprint and an audit trail. Not before.

Who it's for

Centered on whoever signs the delivery decision

Owns the call

The project manager

Owns the delivery decision and its consequences. The forecast isn't wrong. It arrives too late to act on. Lognos closes that gap.

Signs, more often

The client-side controls lead

Feels the same staleness one level abstracted, and more often holds the budget that approves the purchase.

Freed from the assembly

Planners & cost controllers

Spend the month assembling the picture instead of judging it. Lognos takes the assembly; the judgment stays theirs.