See how information moves.
Start with the simple idea below. Then explore one project map at a time.
Every workflow follows the same idea
- Information comes inA need, a question, a file or an observation.
- The team does somethingClarify, design, check or make a decision.
- Useful information comes outA record or result that someone else can use.
Choose a workflow · Full project workflow
Select a group in the map to explore it. Use “Read full size” for larger text; scroll across the diagram on smaller screens.
PROJECT INFORMATION MAP
Full project workflow
How to read this project map
01 · Bring information in
Briefs, stakeholder needs, constraints, project files and observed information establish context.
02 · Connect and review
Requirements, architecture, interfaces, risks and evidence give decisions a traceable basis.
03 · Put outputs to work
Reviewed records, artifacts and handovers support delivery. Operating observations feed issues and future changes.
Solid links show information flow. Dashed links identify review, feedback or conditional paths. Select a numbered group in the diagram or the model chooser for detail.
G1 / 4 MODULES
Intake and context
Inputs, actions, outputs and review points
Information inputs
- Project name, objective, domain, lifecycle and criticality
- Standards, budget/currency, duration, team size and extra context
- Portable project JSON; text-like document content; pasted meeting transcript
Actions and processing
- Structure the brief and suggest domain presets
- Parse/import a project graph; extract candidate meeting objects
- Review generated candidates and convert selected objects into project records
- Display brief/import-derived settings as read-only
Information outputs
- ProjectGraph: Project + typed nodes + relationships
- Draft requirements, risks, decisions, assumptions, actions and issues
- Portable master-project JSON file
Where people review the information
- User reviews extracted/generated content before selecting conversion or graph application; distinguish current click-to-convert behavior from recommended engineering review.
Assessed prototype behavior and limits
- Intake has deterministic generation paths; external generation service availability is not proved.
- PDF/DOC/DOCX selection is not proof of full content extraction.
- Marine meeting sample falls through to a water-plant example in inspected source.
- Settings page is read-only; edits to settings require re-import.
G2 / 9 MODULES
Engineering definition
Inputs, actions, outputs and review points
Information inputs
- Stakeholder needs; objectives; standards and constraints
- Requirement statement, type/level, rationale, acceptance criteria and verification method
- Function/physical-system hierarchy and allocation targets
- Interface endpoints, kind, technical specification, owner and links
- Assumption statement, confidence and confirmation flag; notation/layout selections
Actions and processing
- Author/edit requirements, architecture and interfaces
- Allocate functions and requirements to systems/elements
- Connect needs, risks, verification cases and controlled records
- Apply ontology vocabulary and inspect baselines/traceability
- Generate diagram projections and arrange their layout
Information outputs
- Versioned engineering objects and typed relationships
- Requirement register, architecture views and interface N-squared matrix
- Traceability/baseline listings and assumption register
- SVG/PNG diagrams; browser print-to-PDF
Where people review the information
- User accepts a draft or edits a field to write it to the graph.
- Lifecycle/status transitions and baseline approvals exist as modeled actions; authority and immutable snapshot semantics require separate validation.
Assessed prototype behavior and limits
- Free-text interface technicalSpec does not provide a complete signal-level ICD.
- Declared ontology fields are not proof every field is editable, persisted or checked.
- A baseline label or trace edge does not independently establish a controlled baseline or verified truth.
- Diagram export is implemented; full native SysML interchange/execution is not established.
G3 / 11 MODULES
Assurance and evidence
Inputs, actions, outputs and review points
Information inputs
- Engineering graph and ontology/conformance rules
- Risk causes/consequences, likelihood/impact, mitigations and residual ratings
- Verification case name, target requirement, method, stage and procedure
- Test outcome, measured value and notes/evidence references
- Compliance frameworks, evidence kind/reference/note; signer/certificate number/remarks
- Completeness dispositions; review/scan selections
Actions and processing
- Check requirement quality, relationship legality and artifact completeness
- Calculate modeled risk and readiness/coverage measures
- Plan verification and record manually entered results
- Attach evidence references; record acceptance/compliance sign-off
- Produce discipline findings, risk suggestions and gate checklists
Information outputs
- Quality/conformance findings and proposed corrections
- Risk register, predictions and mitigation suggestions
- VerificationCase, TestResult, Evidence and AcceptanceCertificate records
- Coverage matrices; readiness and completeness scores; review-board findings
Where people review the information
- Test outcomes and evidence are entered by a person; a pass entry is not independent test execution.
- Issue acceptance is gated to a passed result in source and takes Signed by text; authenticated signing authority is unverified.
- Compliance clearing accepts signing-authority text; actual server authority/immutable evidence needs validation.
- Treat reviews and AI suggestions as proposals for human disposition before authoritative release.
Assessed prototype behavior and limits
- Assurance values are calculations over graph assertions; no independent vessel safety approval is demonstrated.
- Confidence/prediction values lack demonstrated calibration.
- Completeness owner/status/not-applicable overrides are page-local.
- Some readiness gates use approved-count or sensor-count proxies.
- Optional K-engine responses are external service paths, not assumed available.
Explore this group: P11 P14 P19 P20 P21 P22 P23 P33 P34 P37 P57
G4 / 5 MODULES
Decisions and changes
Inputs, actions, outputs and review points
Information inputs
- Issue/severity/related-object/resolution
- Decision statement, rationale, alternatives including status quo, falsification criteria and review trigger
- Selected requirement, proposed change text and change type
- Affected requirement/component/risk IDs; cost impact and schedule days
- Trade options, criteria weights, selected option; approval decision and rationale
Actions and processing
- Compare authored alternatives and recompute weighted rankings
- Traverse graph dependencies to estimate change impact
- Draft change requests; review approve/reject/baseline actions
- Run available PRISM pathway and review its record/research/proposed write-back
- Record issue resolution and revisit decisions on review/outcome triggers
Information outputs
- Trade-study matrix/ranking and genuine CSV export
- Affected-object map, cost/schedule estimates and approval warnings
- Decision and ChangeRequest records with proposed/applied modifications
- Issue resolutions, review triggers, falsification criteria and outcome history
Where people review the information
- Human selects alternatives and accepts or rejects proposed changes/write-back.
- PRISM role/process gates are present in source; live backend enforcement is separately qualified.
- Approval should loop back to affected controlled records and subsequent verification, not merely update a displayed score.
Assessed prototype behavior and limits
- Trade-study Generate reveals an authored study and sliders recompute locally.
- Impact simulation is graph-based estimation, not engineering physics simulation.
- PRISM provider calls, research verification and record authority are not inferred from UI labels.
G5 / 5 MODULES
Delivery and artifacts
Inputs, actions, outputs and review points
Information inputs
- Estimated/committed/actual cost, CAPEX/OPEX, CBS code, currency and procurement state
- Supplier scope/quotes/components and owner
- Activity dates, milestone/dependency links, delay risk and cost impact
- Document descriptions/source-object IDs, stated pages and available formats
- Selected document report format or sample-reference action
Actions and processing
- Aggregate stored cost and procurement records
- Display schedule dependencies and supply scope
- Present graph-linked document/report metadata and source previews
- Add a canned sample reference record
- Invoke available browser print or format controls
Information outputs
- Cost/procurement register, totals/variance and supplier register
- Schedule/milestones and delivery-context views
- Document/report cards and previews; PDF browser-print path
- Non-PDF document export success text only — no file in inspected deployed handler
Where people review the information
- Delivery/commercial decisions need a human review based on authorized source evidence; current cost/schedule screens alone do not constitute commitments.
- Select output format only after distinguishing a real artifact from a metadata preview.
Assessed prototype behavior and limits
- No demonstrated ERP integration, supplier quote authentication, full CPM or resource leveling.
- Document page counts are metadata; report assembly/pagination is not established.
- Word/Excel/CSV/JSON document buttons do not create files in confirmed deployed code.
- Do not imply sample-reference add is actual file upload.
G6 / 2 MODULES
Operations and learning
Inputs, actions, outputs and review points
Information inputs
- Modeled Sensor definitions: protocol, component, metric, unit and optional linked requirement
- Ferry modeled SOC, hottest-cell temperature, motor power and charging power
- Existing decisions, assumptions, outcomes and audit/context records
- Memory search and filters
Actions and processing
- Display planned sensor mappings and connection state
- Read/search decisions and assumptions as engineering memory
- Feed reviewed operational findings and outcomes back into needs, risks, issues and decisions when such records exist
Information outputs
- Twin sensor catalogue showing awaiting telemetry
- Engineering memory timeline and confirmation/governance summaries
- Feedback context for revised assumptions, decisions and future project briefs
Where people review the information
- People validate any operational observation and its provenance before using it as verification or risk evidence.
- Outcome review informs a new decision/change cycle; cross-project learning is a future/service-qualified capability unless separately established.
Assessed prototype behavior and limits
- No live telemetry stream, historian or commissioned vessel integration is demonstrated.
- Operational feedback arrow must be dashed/qualified; four planned sensor nodes are not real observations.
- Position/speed reporting is required in the ferry model but has no matching sensor records in the four-sensor list.
G7 / 17 MODULES
Intelligence and oversight
Inputs, actions, outputs and review points
Information inputs
- Current shared project graph and selected lifecycle stage
- Question, query, focal object, task type, traversal depth/mode and view filters
- Stored recommendations and provenance/confidence fields
- Understanding-workbench question/template/role/assurance/target IDs; counterfactual and comprehension inputs
Actions and processing
- Build context packages and traverse/query the engineering graph
- Compute view-specific metrics, health, traceability and actions
- Present recommendations and executive summaries; answer questions through supported local/API paths
- Inspect available agent catalogue and lifecycle guidance
- Call repository workbench service path to compile/attest/export understanding state where deployed
Information outputs
- Project dashboard, action queue, health and executive brief
- Graph/views/thread projections and dependency/impact/traceability findings
- AI context/source previews, relevance/warnings/token estimate
- Answers and recommendations with cited objects and uncertainty labels
- Repository workbench outputs only when service exists: compiled state, evidence lens, counterfactuals/checks and JSON packet
Where people review the information
- A person evaluates recommendations and asks for underlying evidence before applying changes.
- Read-only analysis outputs should feed draft/review nodes, not directly imply approval or authoritative updates.
- Workbench attest/release inputs are repository capability with deployment/authority unverified.
Assessed prototype behavior and limits
- Stored source labels/modelUsed do not prove a model call occurred.
- AI responses inherit stale, missing or inconsistent project records.
- Multiple dashboard counts have different definitions and should not be added together.
- Agent Active labels are catalogue status, not runtime evidence.
- Understanding workbench was not part of the 45-route live sample.
Explore this group: P03 P04 P05 P06 P07 P08 P09 P38 P39 P42 P43 P44 P45 P46 P47 P50 P58
G8 / 7 MODULES
Project stewardship
Inputs, actions, outputs and review points
Information inputs
- Username/password and existing session; project/persona/navigation preferences
- Bundled seed, browser override, imported graph and optional cloud-loaded graph
- Typed graph mutations and optional sync/AI-service request payloads
- Invite email; connector toggle; role catalogue
- Actor/action/field/from/to/date audit and local activity events
Actions and processing
- Resolve session and show role-sensitive interface
- Read/write shared browser graph and local project override
- Attempt configured cloud/service interactions and display errors/results
- Present stakeholder-derived members, simulated invitations and simulated connectors
- Aggregate graph audit arrays and local browser activity log
Information outputs
- Session/error/redirect and selected-project UI state
- Persisted browser graph; optional service requests/sync payloads
- Audit feed and browser activity log
- Page-local Invitation pending/Connected states for preview features
Where people review the information
- Backend authentication, tenant authorization and approval authority must be shown as separate boundary controls, not implied by a role selector.
- No external email was sent; invitation display must not be shown as delivery.
- Authoritative release/sign-off should depend on server identity and durable evidence, which remain qualified in this assessment.
Assessed prototype behavior and limits
- Members invitations and integration connections are simulated, not real external exchanges.
- Local audit arrays/ring buffer are not authoritative immutable server audit.
- Backend implementation exists in repository; successful deployed service execution, backups/tenancy and cross-device durability are not inferred.
- Browser local storage, optional cloud persistence and external AI transmission must be distinct diagram boundaries.
What does a connection tell me?
A connection shows how information relates. It does not prove that a check passed or a decision was approved. Open the model’s review notes and check the current project records.
Browse all inputs and outputs →