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

Our agents and yours access the same engines, over MCP or from Teams, Outlook and other channels. Every confirmation is human-authenticated and attributed. Your organization's know-how remains readable and portable, never locked into a platform or a model.

orchestration.lognos: cascade running
capturing progress ✓_
Field progress
triaging updates ✓_
Update queue
held for planner ✓_
Planner
writing schedule ✓_
Schedule engine
ingesting actuals ✓_
Actuals in
forecasting ✓_
Waterfall
awaiting sign-off ✓_
Cost signs off
simulating composite ✓_
Risk engine
compiling report ✓_
Report
awaiting confirm ✓_
PM confirms
01Field progressSite capture enters the cascade. Cost actuals can start the same loop from the other side.
02Schedule 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 is not carelessness. It is 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 are not 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 is 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 should not have to adopt our interface to get value from our reasoning.

LIVE

Says what it does not 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
reading comms ✓_
Communications
ingesting docs …_
Documents
searching world ✓_
World signals
reading deltas ✓_
Schedule & cost
de-duplicating ✓_
Extract
assigning owners ✓_
Classify
updating register ✓_
Risk register
simulating composite ✓_
Risk engine
compiling board ✓_
Risk board
notifying owner ✓_
Task to owner
opening proposal ✓_
Proposed
awaiting review ✓_
In review
commit not live_
Reviewer
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 is not a black box inside the agent. It is 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 are asked, you are 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 serves

Centered on whoever signs the delivery decision

Owns the call

The project manager

Owns the delivery decision and its consequences. The forecast is not 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.